@IT主催ライブ配信セミナー「運用管理の不安と焦燥にさようなら クラウドネイティブ時代を生き抜く運用改革」の基調講演「セキュリティのログから素早くビジネス価値を得るために、考え抜いたアーキテクチャとは?」で、リクルート セキュリティ戦略グループの日比野恒氏が登壇した。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
2021年6月、リクルートは新規でデータ容量20TB超のログ分析基盤を構築するプロジェクトを開始した。その理由の一部として、日比野氏は、サイバー攻撃が増加し、新しい脅威が次々と登場する現状に対して、今市場で利用されているログ管理製品では、柔軟性に乏しく開発と維持にコストがかかること。加えて、検知や分析における高度なクエリ開発スキルなどが求められるアナリストの確保も年々難しくなっていたことを明かした。
開始当初、日比野氏は2つの観点を大切にしたという。
1つ目は、ビジネスニーズの変化に強いアーキテクチャにすることだ。サイバー脅威の変化に素早く順応しながら防御を進化させるには、ウオーターフォール開発はそぐわない。また、リリースのたびに総合テストを実施する設計も、開発側に負荷がかかり過ぎてしまうので避けたい。さらには、ログ容量やインスタンス数に応じた月額利用モデルも、基盤の柔軟性を損なう要因になるので、別の料金モデルを検討したい。
2つ目は、人材確保のハードルを下げることだ。監視ロジックや高度なクエリ開発には、高度な技術力や経験値のあるエンジニアが必要となる。しかし、そうした人材を雇用、ないし育成するのは時間とコストがかかる。結果、対応できるメンバーに業務が集中してしまい、疲弊させてしまうという問題があった。
日比野氏はこれら課題を解決するために、さまざまな施策に取り組んだ。
1つ目の「ビジネスニーズの変化に強いアーキテクチャ」については、初期リリース後の開発ではアジャイル方式を採用。新規ログを取り込みながら自由にパイプライン構成を変更できるETL(抽出、変換、読み込み)パイプライン開発や、インシデント調査や傾向分析などで新規要件が持ち上がったときに新しい分析ロジックをすぐ取り入れられるダッシュボード開発などを設計した。
2つ目の「人材確保のハードルを下げる」ことについては、ローコード開発、マネージドサービス活用、SQL中心アーキテクチャの3つの考え方で取り組んだ。
ローコード開発は、パイプライン開発とダッシュボード開発で採用した。パイプライン開発では、オンプレミスからはファイル連携、他クラウドサービスからはAPI連携で取り込んだデータを、GUIベースでローコード開発できる「Google Cloud」のマネージドETLツール「Cloud Data Fusion」で収集して、データウェアハウスの「BigQuery」に格納する流れを作った。このBigQuery内のデータを非エンジニアでも分析できるよう、Google Cloudの次世代BIツール「Looker」を導入。エンジニアスキルが高くなくてもダッシュボードを開発できるような仕組みを構築した。同氏は以前から、セキュリティエンジニアではない人たちもログを業務で活用できる、「ログデータの民主化」を実現したいと考えていた。今回のログ分析基盤の新規構築で、その第一歩を踏み出すことになった。
マネージドサービス活用については、「ローコード開発を主軸にアーキテクチャを設計していたら、自然とサーバレスのマネージドサービスを組み合わせた構成になっていた」と日比野氏は言う。ビジネスロジックにフォーカスし、低レイヤーの技術要素はクラウド/マネージドサービスに全振りする方向で組み立てていき、現在の形に落ち着いた。「結果的に、利用したリソースに応じて支払う課金モデルを採用した」(日比野氏)
SQL中心のアーキテクチャを設計することに決めた理由は、数年前に「MongoDB」に代表されるようなNoSQLにおいてもSQLライクなインタフェースが実装されたのを見て、「SQLはなくならない」と確信し、「SQLを扱えるエンジニアの、これまでの知識や経験をそのまま生かしてもらいたい」と考えたこと。データベース監視や障害対応のためのバックアップ、冗長性や可用性を保証するためのクラスタ管理といったデータベースの非機能要件がマネージドサービスに置き換わりつつある現在、「余剰人員をセキュリティの領域で活躍してもらえる」と期待したことなどを日比野氏は挙げた。
だが、ローコードツールにも幾つか運用の課題がある。自動化しづらいのも、その一つだ。
GUIベースのローコードツールは、学習コストが低いというメリットがある。だがそれは裏を返せば、何かしらのタスクを実行するとき、全て手動で操作する必要があるということだ。「パラメーターを少し変更したパイプラインを数百本作るとなったとき、1つずつ手作業で作成することになる。特にCloud Data Fusionは開発時点において、CI/CD(継続的インテグレーション/継続的デリバリー)に未対応で、一度デプロイしたパイプラインを設定変更できない仕様なので、コピーを作成してから設定を変更し、あらためてデプロイし直して既存のものと差し替える必要があり、作業が煩雑になる」(日比野氏)
また、「パイプライン実行環境のバージョンアップも負担が大きい」と日比野氏は言う。CDAP(※)をバージョンアップしたとき、その上で動いているパイプラインがどのような影響を受けるのかを検証するのは、「特に規模が大きくなるほど負担が大きい」(日比野氏)。改善する方法を目下模索しているところだという。
※Cloud Data FusionはOSSであるCDAPのマネージドサービス
アーキテクチャの設計は終わった。だが、それだけでは変化に対して継続的に対応するのは難しい。「どんなに美しいアーキテクチャも、しょせんは手段。それを支えて運用する人やチーム、組織についても併せて考えていくことが大切だ」(日比野氏)
Copyright © ITmedia, Inc. All Rights Reserved.