BigQuery上のデータへのアクセス制御

こんにちは、データエンジニアの中村です。

新卒で入社してから、気づけば2年が経とうとしています。時間の流れは本当に早いものですね。

今回は、私がこれまで取り組んできたデータ基盤におけるアクセス制御に関する技術と取り組みについてお話ししようと思います。

昨日に引き続きデータ基盤関連の記事になりますが、ぜひ最後までご覧ください！

この記事はEnigmo Advent Calendar 2024 の20日目の記事です。

目次

• 背景
• ポリシータグとは
• ポリシータグの利用イメージ
• ポリシータグによるアクセス制御の仕組み
• 使ってみた感想
• まとめ
• 最後に

背景

弊社のデータ基盤はBigQueryを利用しており、社内の個人ユーザーやサービスアカウント経由での各種サービスからアクセスがあります。

データの種類によってはユーザー・グループ毎にカラムレベルでアクセスを制御したいケースが発生することがありました。

以前は、通常のviewと特定のグループに見せたくないカラムをexceptしたviewの二つを作成し管理していました。

図1: アクセス制御方法(旧)

シンプルな構成で直感的に理解しやすいのでこのままでも良さそうでしたが、特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要があるので、要望が多いと対応が大変になってしまいます。

その課題を解決するために、BigQueryのポリシータグという機能を利用してアクセス制御を行おうと考えました。

ポリシータグとは

ポリシータグは、BigQuery上のテーブルで、列レベルでのアクセス制御を可能にするタグ機能のことです。

以下はBigQuery上で実際にポリシータグを設定した時の画像です。アクセス制御したいカラムに対して、作成したポリシータグを紐づけることでカラム単位でのアクセス制御が可能となります。

図2: ポリシータグ

ポリシータグの利用イメージ

イメージを以下に示しました。

図3: ポリシータグによるアクセス制御方法

ざっくり言うと

ポリシータグを作成→ポリシータグに対して権限周りの設定をゴニョゴニョ→アクセス制御したい列に対してポリシータグを設定→アクセス制御したい列の見え方がユーザーによって変わる

といった具合です。

ここで重要なのが、「同じテーブルを見ているのにユーザーによって見え方が変わる」ということです。

これまでは閲覧権限のないカラムをexceptしたviewを作って権限管理していましたが、ポリシータグによって１つのテーブルでそれぞれの閲覧権限に応じて閲覧可能なカラムのみ見せられるようになりました。

図4: アクセス制御方法(新)

現時点ではまだ移行途中ですが、最終的には図1から図4へ完全移行を考えております。

それでは、どのようにして見え方を変えているのかを説明していこうと思います。

ポリシータグによるアクセス制御の仕組み

ポリシータグの挙動を理解する上で重要なのが以下のロールです。

1. roles/datacatalog.categoryFineGrainedReader (きめ細かい読み取り)
2. roles/bigquerydatapolicy.maskedReader (マスクされたデータの読み取り)

名前からある程度想像がつきますね。

1は「ポリシータグが付与されていても、データをそのまま見れる」ロールで、2は「ポリシータグが付与されている場合、データをマスクされた状態で閲覧できる」ロールです。

この二つのロールを利用してアクセス制御を行います。

ポリシータグを作成図3①して、ポリシータグをテーブルへ設定図3⑤するだけだと、どちらのグループも権限エラーでクエリすらできません。

まずは閲覧可能グループの場合ですが、1のロールを付与したIAMポリシーをポリシータグへbinding図3②します。そうすると、閲覧可能グループがクエリしてもポリシータグが付与されているカラムはそのままの状態で閲覧できる状態になります。

次に、閲覧不可グループの場合ですが、2のロールを付与したIAMポリシーをポリシータグへではなくデータポリシーにbinding図3④します。

データポリシーというのはポリシータグに紐づいているデータのマスキングルールを決定するリソースであり、それに対してポリシーbindingを行います。マスキングルールは複数あるので、ケースに応じて適切なルールを選ぶと良いでしょう。

ここまで行うと、閲覧不可グループがポリシータグを設定した列を含むクエリを実行した場合、ポリシータグを設定した列がマスキングルールに従った状態で返ってくる状態になります。

---

まとめると以下のような挙動になります。

図5: ポリシータグの挙動

③の状態になってしまうと、そもそもクエリが実行できなくなってしまうので、そうならないように全てのグループ・ユーザーが①or②の状態になることが理想です。

使ってみた感想

約1年半利用しましたが、正直なところ当初の課題であった「特定のカラムが閲覧不可のグループから要望があるたびにViewを用意する必要がある」というケースがあまり発生しなくなったので、利用前後でそこまで恩恵を感じておりません。

ですが、アクセス制御方法を移行することによって将来的に以下のメリットがあると思いました。

• 組織が拡大してさらに細かいアクセス制御が必要になった場合、ポリシータグの方が対応が容易
• セキュリティポリシーの一元管理が可能になり、管理コストが削減される

デメリットももちろんあり、以下のような状況に陥りました。

• テーブルへのポリシータグ付与をAirflowで行なっており、そこで利用しているAPIがタイムアウトになり連携処理が失敗・遅延してしまい後続処理へ影響が出てしまった。
• 新規で作成したSAが図5③の状況になり、各所からこれまで以上に権限付与依頼が届くようになった。

APIのタイムアウトの件は、暫定でリトライ回数を増やして対応しました。

権限付与依頼の増加は、デメリットというよりメリット寄りかもしれません。というのも新規ユーザーがデータ基盤にアクセスする場合はどのような権限を持つべきかを考えるべきだと考えているので、その状態が作れていることはプラスであると思います。 (あまりに多くなってきたらもっと良いやり方がないか考えます。。)

まとめ

現段階では総じてポリシータグによるアクセス制御への移行は個人的に微差でプラス寄りな気がします。

最終的に移行してよかったと思えるように日々運用方法は改善していこうと思います。

最後に

最後までご覧いただきありがとうございました！

明日は佐伯さんよりAppSheetに関する記事をお届けします。お楽しみに！

---

株式会社エニグモ すべての求人一覧

hrmos.co

Lookerで大幅にコスト削減できた話

こんにちは、データエンジニアの中村です。

弊社ではBIツールとしてGoogle Cloudから提供されているLookerを利用しています。

Lookerの利用者も徐々に増えており、日々データ活用が進んでいることは嬉しいですが、それと比例して気になるのはダッシュボードの表示速度やクエリコスト等のパフォーマンスです。

最近AggregateAwarenessという機能を利用してパフォーマンスを改善することができたので、その機能を利用するに至った背景と、その改善効果を紹介したいと思います。

AggregateAwarenessの詳細な使い方は説明しないので、その点はご了承ください。

この記事はEnigmo Advent Calendar 2024 の19日目の記事です。

目次

• 背景
• AggregateAwarenessとは
• 利用した結果
• メリデメ
• まとめ
• 最後に

背景

弊社のデータ基盤はBigQueryを採用しており、LookerからBigQueryへのクエリでどのくらいのコストが発生しているかをモニタリングしています。

今年の8月ごろからクエリコストが増加していることが判明し、原因調査から始めました。

Lookerのコスト推移

原因はアクセス量の多いダッシュボードにスキャン量の大きいLookを追加したことによるものでした。

対策としては、Lookに対応した軽量のデータマートを用意してあげることでコストを抑えるといった方法があると思いますが、パネル毎にデータマートを用意するのは大変ですし、メンテナンスコストも高くなります。

かといって、DWH層を一から整備していくのは時間がかかりそうです。

そこで、両者のメリットを兼ね備えた方法としてAggregateAwarenessという機能に辿り着きました。

AggregateAwarenessとは

AggregateAwarenessとは、データマートに相当する、事前に集計されたテーブルを自動で作成し、クエリの際にそのテーブルを自動で認識してくれる機能です。

ざっくりとした手順を以下に記載しますが、本題ではないので詳細は割愛します。利用方法はクラスメソッドさんのこちらの記事が参考になりました。

①AggregateAwarenessを適用したいLookが参照しているExplore画面を表示
↓
②Explore画面より、AggregateAwareness用に自動生成されたLookMLをコピー
↓
③コピーしたLookMLを、対象のexploreが定義されているmodelファイルのexploreブロックへコピペ
↓
④Exploreからクエリを実行すると、BigQueryにLookMLで指定した条件で集計されたテーブルが作成される
↓
⑤次回以降は④で作成された集計テーブルへクエリしに行ってくれるので、クエリパフォーマンスが向上する

この方法だと、テーブルの作成をLooker側で行なってくれるので、工数をかけずにマートの作成が行えてよかったです。

また、パネルが不要になったら、コピペしたLookMLと自動で作成されたテーブルを削除すればクリーニングが済むので、後片付けが楽そうだと感じました。

紹介はここまでにして、AggregateAwarenessを利用した結果の方を説明していこうと思います。

利用した結果

AggregateAwareness適用後のコスト推移

グラフを見ると一目瞭然ですが、適用前後で大幅にコストを削減することができています。

修正した日付が11月14日なので、11/10の週から減少傾向になり、11/17の週から一気に削減効果が現れていますね。

クエリ一回あたりのコストも連動して減少しているので、クエリ回数が減ったことによる効果ではなさそうです。

コスト	期間①※1	期間②※2	減少率
クエリ全体のコスト(円)	(省略)	(省略)	71.8%
クエリ1回あたりのコスト(円/クエリ)	13.75	3.53	74.3%

※1期間①: 10/14~11/13(修正日前日から直近1ヶ月)
※2期間②: 11/14~12/15(修正日当日から1ヶ月後まで)

具体的な数値だと、適用前後1ヶ月で全体のクエリコストを約71%、クエリ一回あたりのコストを約74%削減できました！

また、今回の対応を行うきっかけとなったパネル以外にもAggregateAwarenessを適用したことで、コスト増加前の期間よりも改善されていました。

コスト	期間③※3	期間②※2	減少率
クエリ全体のコスト(円)	(省略)	(省略)	34.0%
クエリ1回あたりのコスト(円/クエリ)	7.17	3.53	50.8%

※3期間③: 7/1~7/31(コスト増加前)

平常時と比較しても約50%のコスト削減効果を得られたので、年間を通してかなり効きそうですね。

---

なお、クエリパフォーマンスも改善されており、平常時の平均実行時間はは4秒程度だったものが、適用後は3秒程度まで減少していました。

クエリの平均実行時間の推移

コスト削減と同時にユーザビリティを向上させることもできました！

メリデメ

AggregateAwarenessを使用してみて、以下のメリットがあると感じました。

メリット

• 簡単にデータマートを作成でき、削除する際もクリーニングが簡単
• クエリのパフォーマンスが課題になっている場合、改善効果が大きい

ただし、上記のメリットはあくまで短期的な視点で見た時のものであり、中・長期的な視点で考えると以下のようなデメリットもあると感じました。

デメリット

• パフォーマンスが低下するたびに対応が必要で、イタチごっごになってしまう。（スケーラビリティの低下）
• AggregateAwarenessの利用が膨大になると、メンテナンスコストが増加しそう。(このLookMLってどのLookに対応してるんだっけ？とかが起こる)

これらのメリデメを加味してバランスよく利用していけばかなり有用な機能だと思いました。

メリットが大きすぎるので、個人的にはどんどん利用していきたいです。

まとめ

• AggregateAwarenessを利用することで、Lookerのコストを約70%削減することができました。

• 平均クエリ実行時間も減少し、ユーザビリティの向上も同時に行えました。

• 「まだ利用していない&パフォーマンスを改善したい」場合は利用をお勧め！

最後に

最後までご覧いただきありがとうございました！

明日の記事の担当は、本日と同じくデータエンジニアの中村です。お楽しみに！

---

株式会社エニグモ すべての求人一覧

hrmos.co

システムリプレイスを乗り越える！成功体験に導く3つの心構え

こんにちは。エンジニアの竹田です。
BUYMAの検索システムやMLOps基盤の開発・運用を担当しております。
こちらはEnigmo Advent Calendar 2024の18日目の記事です 🎄

はじめに

2024年もいよいよ年の瀬ですね！寒さが増すこの季節、みなさまいかがお過ごしでしょうか？

早速ですが本記事の主題のシステムリプレイスについてです。
ここ言うシステムリプレイスとは、老朽化したシステムの刷新、管理目的での移設など、既存システムがあり、それを何かしらの方法で置き換えることを指しています。
例えば、古くなったオンプレミス環境をクラウドに移行したり、データベースをより新しいものに入れ替えるといった作業も含まれます。

サーバサイドから下位のレイヤを担当している方々は、システムリプレイスを行う機会が割と多いのではないでしょうか。
実際に自分もエニグモに入社してからもそうですが、それ以前からも新規システムを構築するよりはシステムリプレイスを行うことが多いと感じています。

• 今までの実績
  • 各種検索システムのリプレイス
  • MLOpsシステムのkubeflow pipelines→vertex ai pipelinesへのリプレイス
  • アカウント検知システムのリプレイス

どんなシステムでも老朽化が進むため、定期的なリプレイスが必要です。
気が付くとサポート期限間近であったりということは少なくないのではないでしょうか。
ただ、新しいもの作りという訳ではないので、なかなかモチベーションを上げ辛い作業ではないかなと思います。

また、旧システムとインプットやアウトプットは変えない、というのが命題となるので、結果比較に時間を要したりとナーバスになる作業も多いです。

そんな中でも、モチベーションを高く保つために自分が意識していることを紹介したいと思います。

システムリプレイスのモチベーションを高めるために

改善のチャンスと捉える：システムの価値を高める！

何か付加価値を提供できないかを考えます。
システムコストや学習コストの兼ね合いもありますが、思い切って足回りやミドルウェアの置き換えなど検討しても良いと思います。

• コスト削減
  • 新たなマネージドサービスの利用
  • 多めに見積もって構築されていたリソースの削ぎ落とし
• システム強化
  • 少し気になっていたコードの修正
  • 構成周りの定義での一工夫
• マイクロサービス化
  • 機能の一部を切り出して影響を局所化
• 監視強化
  • 迅速な障害対応、柔軟な運用

学びのチャンスと捉える：自身のスキル底上げ！

少なくとも現状を一切変更しないリプレイスはあまり存在しないと思います。
例えば、旧システムのデータベースを調査中に、想定外のデータ構造や運用上の工夫を発見することもあります。それが新システム設計のヒントになることもしばしばです。
そう考えると、以下の点で新しく学びを得られる機会があります。

• 各種ライブラリのバージョン最新化
  • 動作差異の確認、理解
• あまり深く知らない言語の理解
  • どの言語でも固有の特徴がある
• 旧システムの構成や思想の理解
  • wiki等が残っていれば確認、当時の思想が全く分からないこともある...
  • とにかく旧システムを把握しないことには作業を進めづらい

アウトプットのチャンスと捉える：学びを共有して価値を広げる！

どういった方法でシステムを刷新したか、その意図など、技術ブログなどで外部発信する機会を得られます。
技術ブログの他にも、社内勉強会やカンファレンスでのLT（ライトニングトーク）なども該当するかと思います。
自分もこの点はあまり実践できていないので、自戒の意味も込めて記載しています。

• 自身の技術棚卸し
  • こういった機会を作ることで、振り返りの機会を設ける
• 外部向け文章作成の機会
• 企業ブランディングへの貢献

より気持ちを高めるために

関わったことのなかった方と関わりを持てる可能性がある

過去担当していた方と関わりを持ち、人間関係を広げる機会になる可能性があります。
怯むことなく関わりを持てるようにしましょう。

今どきな言い方をしてみる

slack等でやりとりする際、リプレイスではなく モダナイズ という言葉を使ってみたりしています。
ただし、クラウドの新機能を利用したり、インフラやアプリの構成を大幅に見直すような場合でないと名前負けした感じになるので注意が必要です。

最後に

以上のようなことを意識して取り組んでいるため、比較的楽しくシステムリプレイスを行っていると思っています。
システム規模が大きくなればなるほどリプレイスは大変になるので、立ち止まって特定の機能を切り出せないかを考えたりするのも良いと思います。

みなさんもシステムリプレイスを楽しむ方法を見つけて、エンジニアとしての成長を一緒に楽しんでいきましょう！

明日の記事の担当は同グループの中村さんです。お楽しみに！！

---

株式会社エニグモ すべての求人一覧

hrmos.co

PHPerがRubyistになろうとしてつまづいたところ③SQL

こんにちは！WEBアプリケーションエンジニアの小松です！

この記事は[Enigmo Advent Calendar 2024]の17日目の記事です。  

Railsの場合: 自動的に日付オブジェクトとして認識

RailsはActiveRecordのORMを利用する場合だけでなく、rawクエリを用いた場合でもdate型はRubyのDateオブジェクトに変換されます。そのため、日付フォーマットの変換を簡単に記述できます。

サンプルコード（Rails）

テーブル定義

# migration
create_table :events do |t|
  t.date :event_date
  t.timestamps
end

rawクエリの利用

result = ActiveRecord::Base.connection.execute("SELECT event_date FROM events LIMIT 1")
raw_date = result.first["event_date"] # => #<Date: 2023-12-13>

puts raw_date.strftime('%Y%m%d') # => "20231213"

ポイント

• event_dateはRubyのDateオブジェクトとして取得される。
• .strftimeメソッドを直接利用してフォーマットを変更可能。

---

Laravelの場合: 明示的な型変換が必要

Laravelでrawクエリを使用した場合、デフォルトではdate型は文字列として取得されます。そのため、フォーマットを変更する際は、明示的にCarbonオブジェクトなどに変換する必要があります。

サンプルコード（Laravel）

テーブル定義

// migration
Schema::create('events', function (Blueprint $table) {
    $table->date('event_date');
    $table->timestamps();
});

rawクエリの利用

use Illuminate\Support\Facades\DB;
use Carbon\Carbon;

$result = DB::select("SELECT event_date FROM events LIMIT 1");
$rawDate = $result[0]->event_date; // => "2023-12-13" (文字列)

$carbonDate = Carbon::parse($rawDate);
echo $carbonDate->format('Ymd'); // => "20231213"

ポイント

• event_dateは文字列として取得される。
• PHPのCarbonライブラリを利用して明示的に日付オブジェクトに変換する必要がある。

---

RailsとLaravelの比較表

特徴	Rails	Laravel
rawクエリでのdate型の扱い	自動的にDateオブジェクトとして認識される	文字列として取得される
日付フォーマットの変更	.strftime('%Y%m%d')が直接利用可能	Carbon::parse($date)->format('Ymd')が必要
追加の変換処理の必要性	不要	必要
デフォルトの開発者体験	日付操作が非常に簡潔で直感的	明示的な型変換が必要で、柔軟性が高い
適用範囲	ActiveRecordでもrawクエリでも同じ	Eloquentとrawクエリで挙動が異なる

---

開発者の観点からの結論

Railsのメリット

• 開発効率が高い: 日付型は自動的にDateオブジェクトとして認識され、変換処理を意識する必要がありません。
• 統一性がある: ActiveRecordでもrawクエリでも同じように扱えます。
• 時間をかけてハマる前に、まず .to_sqlでクエリを確認 する習慣をつけると、デバッグがスムーズになります！

Laravelのメリット

• 柔軟性が高い: Carbonを使えば、細かい日付操作やタイムゾーン操作が可能です。
• 設計の自由度: 明示的な変換により、モデルやユースケースに応じた日付処理を柔軟に適用できます。

Railsは「標準的な処理が簡潔」、Laravelは「柔軟性を重視」といったフレームワークの哲学の違いが、日付型の扱い方にも表れています。どちらを選ぶかはプロジェクトの要件やチームの好みに依存しますが、簡潔さを求める場合はRailsが有利です。

PHPerがRubyistになろうとしてつまづいたところ②コンソール

こんにちは！WEBアプリケーションエンジニアの小松です！

この記事は[Enigmo Advent Calendar 2024]の16日目の記事です。  

コンソールを使ったデバッグは開発において非常に重要です。フレームワークや言語ごとに特性が異なるため、それぞれの仕組みに慣れる必要があります。以下にPHPやRailsを例に、デバッグ手法や注意点を詳しく解説します。

---

1. PHPのデバッグ方法

PHPにはRuby on Railsのような標準的なコンソール機能（例：rails console）が存在しません。そのため、デバッグの際には以下の手法を使うことが一般的です。

• var_dump()の利用
  PHPでは主にvar_dump()が使われます。これはCLIからの実行でもWEBブラウザ経由のアクセスでも有効です。
  例:

  $data = ['name' => 'John', 'age' => 30];
  var_dump($data);
  

• CLIでのPHPスクリプト実行
  テストスクリプトを作成してCLIから直接実行する方法もあります。これにより、サーバーを介さずにデバッグが可能です。

---

2. Railsのコンソール機能

Railsには標準でrails consoleが用意されており、デバッグやテストに非常に便利です。ただし、注意すべき点もいくつかあります。

• 関数のテストが容易
  Railsのコンソールでは、関数やクラスを直接呼び出してテストできます。
  例:

  def greet(name)
    "Hello, #{name}!"
  end
  
  puts greet("Alice") #=> Hello, Alice!
  

• デバッグにおける注意点
  Railsコンソールでのデバッグにはpを使用しますが、PHPのvar_dump()と異なるため、切り替えを忘れることがあります。
  例:

  data = { name: "John", age: 30 }
  p data #=> {:name=>"John", :age=>30}
  

• コード変更時の再起動
  コードを変更した場合、Railsコンソールに入り直す必要があります。これを忘れると、古いコードのままデバッグを続けることになり、時間を無駄にする原因になります。

---

3. RSpecでのデバッグ

RSpecのデバッグでもコンソールと似ています。以下に注意点と手法を挙げます。

• pを利用したデバッグ
  RSpecでは、ログを確認するよりもpを使う方が効率的な場合があります。しかし、つい忘れてしまうことも多いです。
  例:

  it "tests addition" do
    result = 2 + 2
    p result #=> 4
    expect(result).to eq(4)
  end
  

• コード変更時の挙動
  RSpecコードそのものを変更する場合、通常は何もせずにテストを実行できます。しかし、テスト対象のロジックを変更した場合、特定の環境では注意が必要です。

• コード変更と反映
  テスト用のコード変更は即時反映されますが、今の開発環境では実際のアプリケーションコードを変更した場合はDockerコンテナを再起動する必要がある場合があります。この手順を忘れると、古いコードでデバッグを進めてしまう可能性があります。

  手順:

  1. コードを変更する。
  2. 以下のコマンドでコンテナを再起動する。

---

結論

PHPやRails、RSpec環境それぞれに特有のデバッグ手法と注意点があります。特にRailsやDocker環境ではコード変更時の再起動を忘れがちになります。また、各環境でのデバッグ手法に慣れることで、無駄な時間を減らし、生産性を向上させることができます。

PHPerがRubyistになろうとしてつまづいたところ①シンボル？

こんにちは！WEBアプリケーションエンジニアの小松です！

この記事は[Enigmo Advent Calendar 2024]の15日目の記事です。  

PHPの場合

model['full_name']

こういう変数の持ち方を連想配列と呼んでいただけなので、シンボルキーという言葉と発想がなかったです。

呼び出し方でも

model['full_name'], model[:full_name], model.full_name

などがあり、

<%= debug model %> やログでオブジェクト全体の値が取れてもキーの持ち方が違って取得するのに時間がかかることがありました。

なので、呼び方の具体例や呼び出し方を記載しました。

model['full_name'] のような形式は、文字列キーを持つハッシュから値を取得する方法です。このような形式でのアクセスは、Rubyの基本的なハッシュオブジェクトの操作です。

呼び方の具体例

文字列キーを使ったハッシュアクセス

Rubyでは、ハッシュのキーとして文字列（String）を使う場合に、この形式でアクセスします。

model = { 'full_name' => 'AIR JORDAN 13(エアジョーダン13)' }
puts model['full_name']  # => "AIR JORDAN 13(エアジョーダン13)"

文字列キーアクセスを使う場面

JSONパーサーからのデータ: JSONをRubyでパースした場合、デフォルトではハッシュのキーが文字列になります。

シンボルキーを使ったハッシュアクセス

Rubyでは、ハッシュのキーとしてシンボル（Symbol）を使うことも一般的です。この場合は、:full_name のようにしてアクセスします。

model = { full_name: 'AIR JORDAN 13(エアジョーダン13)' }
puts model[:full_name]  # => "AIR JORDAN 13(エアジョーダン13)"

オブジェクト形式（OpenStruct）のアクセス

OpenStruct を使うと、ドット演算子（.）でプロパティにアクセスできます。

require 'ostruct'
model = OpenStruct.new(full_name: 'AIR JORDAN 13(エアジョーダン13)')
puts model.full_name  # => "AIR JORDAN 13(エアジョーダン13)"

確認方法

model.class を実行することで、オブジェクトがハッシュなのか、OpenStruct なのか、あるいは別の型なのかを確認できます。その型に応じたアクセス方法を選びましょう。

クラス内のインスタンス変数の確認方法

インスタンス変数の取得方法も初めは時間がかかりました。

docs.ruby-lang.org

p obj.instance_variable_get(:@foo) 

このように取得するみたいです。

シンボルはRubyのみ存在?

Python、PHP、C、Go、JAVAなどには存在せず、Javascriptには存在するけど、挙動が少し違うようです。

qiita.com

慣れればメリットもあるとの事ですが、他の言語にない概念なので、Ruby使い始めは正直紛らわしかったです。

表計算ツールでのサーバ管理台帳を卒業してDCIMツールのNetBoxに移行のことはじめ

こんにちは、インフラグループの片桐です。

この記事はEnigmo Advent Calendar 2024の 14 日目の記事として、サーバ機器管理台帳を表計算ツールから OSSの「NetBox」に移行した取り組みについて紹介します。

はじめに

サーバ機器やネットワーク機器、各機器に付随するIPアドレスの情報など、サーバ機器や関連情報をまとめる為に「機器管理台帳」は欠かせないものになっています。その中で、機器管理台帳はExcelやGoogle スプレッドシート等の表計算ツールで管理されているケースもよく見られます。

表計算ツールを台帳として機器管理している場合、台帳の規模が拡大するにつれて、管理すべき各種情報が複数のシートやファイルに分散しがちです。これにより管理コストが増大し、整合性の維持も難しくなります。こうした状況に心当たりのある方も多いのではないでしょうか。

弊部署も同様に、表計算ツールを用いた煩雑な機器管理に悩まされていました。そこで、データセンターのインフラ管理（DCIM)とIPアドレス管理(IPAM)を兼ねるツールであるNetBoxを導入し、機器情報管理の一元化・整合性維持を試みました。本記事では、機器管理台帳の表計算ツール管理からNetBox移行について、取り組み内容、移行に際する知見等を紹介します。

 用語の整理

DCIM

DCIM(Data Center Infrastructure Management)は、データセンターに関連するサーバ機器やネットワーク機器、ラック、配電や配線、設備など、さまざまなリソースを管理・可視化するためのツールや手法のことです。DCIMおよびDCIMツールを導入することで、ハードウェア配置や容量、ネットワーク接続状況などを一元管理することが可能となります。

IPAM

IPAM(IP Address Management)は、ネットワーク内で使用されるIPアドレスを一元的に管理し、その割り当てや利用状況、変更履歴などを可視化・追跡するためのツールや手法のことです。IPAM及びIPAMツールを導入することで、利用可能なアドレス空間のシステム的な管理と、管理に伴ったIP重複割り当ての予防等が可能となります。

NetBox

NetBoxは、DCIMとIPAMの機能を併せ持つOSSです。サーバ機器やラック構成、IPアドレス、ケーブル接続など、データセンターまわりの情報を一元的に、かつわかりやすく管理することに特化しています。 WebインターフェースやREST APIを通して各機器やネットワーク関連のデータを登録・編集・参照できるため、機器情報の管理をするだけでなく、管理の簡略化・自動化も可能です。 お試しで触りたい方向けの公式デモ版サイトも公開されています。 github.com

移行の背景と課題

これまで、弊部署の機器管理台帳には複数ファイル/複数シートを跨ぐGoogle スプレッドシートを使用しており、以下をはじめとする各種情報を管理していました。

• ハードウェア関連：機材情報、シリアル番号、ラック配置、納品日/保守期限、各機材のLAN接続状況
• ホスト関連：ホスト名、各NICごとのIPアドレス割り当て状況
• etc...

台帳上の各機器について、あるシートではホスト名とIPアドレスの紐づけ、あるシートではホスト名とラック上の設置位置の紐づけ...等、1箇所のデータを更新した際に関連するデータを複数シート上で合わせて更新する運用でした。

一方、この管理方式には以下の様な課題もあります。

• 台帳更新の煩雑さ:
  • 1つの機器について複数ファイル/複数シートを跨いで情報が登録されている場合。
  • シート上のある箇所を変更した際、別シートや別セルの依存箇所も特定して修正する必要がある。
  • 依存箇所を漏れなく特定できる運用フローや仕組み構築が必要になる。
• 整合性管理の困難さ:
  • 台帳更新の煩雑さ にも関連。
  • 依存箇所の修正漏れが起きやすい状況下にて、依存データ間で整合性の取れていないデータが発生した場合に事実確認の手間が発生する。
• 外部連携の困難さ:
  • 機器管理台帳に限らず、表計算ツールで作成された各種データファイルが完全なCSV形式で構築されていない場合。
  • 台帳上に存在する情報を読み込んでプログラマブルに利用したい場合や、外部のシステムにデータを取り込む際、各環境が扱える状態に一度変換する手間がある。

これらの課題に対してNetBoxを導入し、対応を試みました。

NetBoxのデプロイ

NetBoxのデプロイ先として、社内向けツール用に構築しているEKS(Amazon Elastic Kubernetes Service)クラスタ上に構築しました。

インストールには、Netbox CommunityのGitHub上で公開されているHelmチャート(netbox-chart)を使用しました。

github.com

helmを利用する場合は利用ガイドを読みながら、ご自分の環境に合わせてvalues.yamlの各値を変更してセットアップする流れとなります。 特に管理者ユーザ周りの設定値はログイン時に使用するため、ご利用の環境に合わせて事前設定することをおすすめします。

NetBoxへのデータ登録

NetBoxに登録できる項目について

データの登録を始める前に、既存の機器管理台帳では何の情報を管理しているのか、NetBoxには何の情報を登録できるのかを一通り把握しておくことを推奨します。

ドキュメントをご参照いただくと分かる通り、NetBoxに登録できる項目は多岐にわたり、かつきめ細かい情報を登録であるため、最初から全ての情報を入れ込むことが難しい場合も想定されます。 (以下NetBox ドキュメントの models 配下の大項目、並びに大項目配下の詳細情報を各機器/各グループ毎に入力可能となっています。)

github.com

もしスモールスタートで「データセンタ内の機器情報、ラックへの機器マウント情報、各機器へのLAN配線、VMホストとゲストVMの紐づけ、各NICへのIPアドレスアサイン」程度で運用を開始したい場合は、以下図のmodel項目を参考に入力していくことで簡素版な環境を構築可能です。

データの登録

NetBoxの導入を検討した当初はスプレッドシート上に散在していた情報を1件ずつ確認しながら手動で登録することも考えていましたが、登録すべき情報を整理していく中で、数百台以上の機器やIPアドレス、接続情報等をすべて手動で移行するのはあまりにも現実的ではない事に気付きました。

一方、NetBoxには機器追加/変更/削除等のデータ操作を楽にする為の仕組みが複数整備されており、一括でのデータ操作が可能となっています。

• CSV/YAML形式での一括インポート:
  • NetBoxのWEBインターフェースの機能として、CSV/YAML形式でのデータの一括インポートに対応しています。
  • 登録するデータを各形式に整形して事前に整備出来ている場合、各model毎のWEB UI上から楽にデータをインポート可能です。
  • 1行目に各modelに対応するヘッダを、2行目以降に登録するデータを入力する形で定義します。

CSV形式インポートの入力例

• REST APIでのデータ操作:
  • NetBoxに実装されているREST APIを活用することで、各種データ操作をプログラマブルに行う事も可能です。
  • CSVでのインポートはデータの登録のみ可能ですが、APIを利用することでCRUD各処理を複雑な条件式を絡めて実行することも可能となります。
  • Netbox API Document

上記2種類の一括操作方法を実施して、既存の機器管理台帳上のデータを移行していきました。

スプレッドシートから移行する際の知見

移行前の情報を整理した上で、完全に正規化されたCSVを作成するべき

移行前のスプレッドシートには現状との乖離として、例えば以下の様な不整合が発生していました。

• 新しいホストに付け替えたIPアドレスが古い機器に付随されたままになっている。
• ホスト名を変更したが、旧ホスト名のまま台帳に登録されている。

不整合を一つ一つ修正するのは非常に手間の掛かる作業となる上、独自管理の形式から完全な状態のCSV形式に落とし込むことは、手間と時間の掛かる作業となります。

一方、NetBoxには強力なCSVインポート機能が備わっているため、一度完全な状態のCSVを作成してしまえば、NetBoxの運用は直ぐにでも開始可能です。 私は不整合の解消作業は実施したものの、完全な状態のCSVを作成する前に移行を始めてしまった為、変更が必要な所はREST APIを使用して適宜修正する形での対応となりました。

再度移行作業を実施する機会のある際には、完全に正規化されたCSVを作成してから実施すべきと実感しました。

NetBoxに登録する情報の精査と入力先カラムの確認

前述の完全に正規化されたCSVを作成した後は、CSV上のカラムをNetBox上のどのモデルに入れるかを予め検討しておくべきでした。 ラックの情報は dcim > racksに、機器のモデル名やシリアルは dcim > devicesに、IPはipam > ip-addressesに登録出来る、あるいはこの項目について入力できそうな項目が存在しない、等を先行して把握しておくべきでした。

例えば、NetBoxには機器の納品日や保守期限といった項目を入力出来る箇所が標準項目としては存在しません。 そのため、機器情報の自由記述欄となる Comment カラムに入力するか、カスタムフィールドを追加することで、標準機能外の情報管理もNetBox上で可能になります。

一括登録を実施する前に、整理されたCSVの項目とNetBoxの入力項目を比較して、このデータは何処に入るのか？を明確にしておくとスムーズなデータの投入が可能でした。

カスタムフィールドで機材納品日の入力欄を追加する例

NetBox導入によって感じたメリット

情報の一元管理と可視化:

NetBox移行後はIPアドレス、機器モデル、シリアルナンバー、物理配置、接続関係など、あらゆる情報をNetBoxで一元的な管理が可能となりました。 スプレッドシートを利用していた頃は、ある箇所を修正した際依存する情報の修正を、複数シート/複数ファイルに跨って手動で行う必要がありました。 NetBox移行後には依存情報の修正も行われるため、整合性保持にも寄与します。

エクスポート/インポートの柔軟性:

前述の通り、NetBoxにデータを登録する際はCSV/YAML形式でのインポートが可能です。 また、NetBoxに登録されている情報は、CSV/YAML形式でのエクスポートも可能であるため、将来的に別の管理基盤へ移行する際にもデータ移行が容易になることが見込まれます。

拡張性と自動化:

NetBoxにはREST APIや各種WebHookが実装されています。APIによる台帳上のデータの一括操作が可能になった他、WebHookによって台帳に新規機材が追加された際にSlackなどチャットツールに通知する等の対応が可能となりました。別途仕組み作りを実施することで柔軟な対応が可能となるため、今後の拡張性として期待が高まりました。

サーバラックの情報可視化例。ラックの色のついている部分には登録した機器が紐づいている

まとめ

スプレッドシートからNetBoxへと台帳管理を移行した結果、情報一元化や更新作業の効率化が期待できる基盤が整いました。初期構築やデータ整備に手間はかかりましたが、その分、長期的な整合性維持と運用自動化の可能性が大きく広がりました。

一方、現時点では、NetBoxの基本的な機能を用いて、ハードウェアとIPアドレス、簡易な接続情報を一元管理する段階にとどまっています。今後は運用を通じてAPIやWebHookの活用やNetBoxのプラグイン導入など、さらなる効率化と可視化を進めていきたいと考えています。

明日の記事の担当はWEBアプリケーションエンジニアの小松さんです。お楽しみに。

---

株式会社エニグモ すべての求人一覧

hrmos.co