データ容量20TB超のログ分析基盤構築プロジェクトに見る、クラウドネイティブ時代を生き抜く運用改革：アジャイルやローコードを取り入れ、「ログデータの民主化」を実現

＠IT主催ライブ配信セミナー「運用管理の不安と焦燥にさようなら　クラウドネイティブ時代を生き抜く運用改革」の基調講演「セキュリティのログから素早くビジネス価値を得るために、考え抜いたアーキテクチャとは？」で、リクルート セキュリティ戦略グループの日比野恒氏が登壇した。

[谷崎朋子，＠IT]

ログ分析基盤構築に大切にした2つの観点

　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のマネージドサービス

　アーキテクチャの設計は終わった。だが、それだけでは変化に対して継続的に対応するのは難しい。「どんなに美しいアーキテクチャも、しょせんは手段。それを支えて運用する人やチーム、組織についても併せて考えていくことが大切だ」（日比野氏）

DevOpsを支えるにはどのような組織が必要なのか

　では、DevOpsを支えるにはどのような組織が必要なのか。

　まず日比野氏は「タックマンモデル」を例に解説した。タックマンモデルは、チームが形成されて（成立期）、活動する中で異なるやり方見解でぶつかり合いながら（動乱期）、そうした違いを乗り越えて共通の目標を掲げ（安定期）、チームとして機能し始めて（遂行期）、目的を達成してプロジェクトが終了する（解散期）という組織の成長モデルだ。

　問題は、DevOpsチームの場合、手掛けているサービスが終了しない限り、解散期が来ないことだ。終わりがなかなか来ないので、人員の入れ替えが起こるたびに成立期〜遂行期を繰り返すことになる。

　気を付けなければならないのは、「262の法則」の発動だ。262の法則とは、どのような組織、集団であっても、人材の構成率は、優秀な働きを見せる人が2割、普通の働きをする人が6割、貢献度の低い人が2割になる理論のことだ。

　「スクラムマスターやプロジェクトマネジャーはそうなるリスクを認識し、自律型多機能組織の維持を心掛けることが大切だ」（日比野氏）

考える力と俯瞰力

　日比野氏は、予測の難しい変化に対応するために必要なソフトスキルとして、仕組みを理解しながら発想や工夫をこらす「考える力」と、抽象と具体を行き来できる「俯瞰（ふかん）力」についても触れた。

　だが、この考える力について、「これまで良しとされてきた品質向上施策には、考える力を奪う危険性がある」と日比野氏は危惧する。

　理由の一つは、アウトソースだ。アウトソースの例として日比野氏は、テンプレート化（ナレッジのアウトソース）、自動化（システムへのアウトソース）、外部の専門家組織の活用（コンサルタントやSIerへのアウトソース）などを列挙した。「こうしたアウトソースは効率化と品質向上のメリットがある一方で、基礎を構築する人は頭を使うが、できたものを使うだけの人は、構築する過程で得られるはずの考える機会を失うので、考える力が衰え得る」（日比野氏）

　しかも、「日本は特にこうした負のスパイラルに陥りやすい」と日比野氏は指摘。例えば終身雇用を前提とした人事制度が多い日本では人を簡単にレイオフできないので、市場や情勢の変化が激しい場合、先が読みにくい状況下においてはアウトソーングしてしまう。そして、取りあえずアウトソーシングして、ある傾向が継続するまで雇用を見送るが、気付いたときには組織は考える力を失っている。

　また、スピード重視も原因の一つだ。日本の製造業は、「メイド・イン・ジャパン」という高品質ブランドで成功してきたが、それ故に品質偏重の傾向があった。しかし近年では納期（デリバリー）の遅れにフォーカスが当たり、市場にどれだけ速く価値を提供できるかに重きが移っていった。

　「もちろん、それ自体は悪いわけではない。市場からすぐにフィードバックを得られるし、早いタイミングで損失を最小限にとどめることができる」

　そう日比野氏は肯定しながら、問題はスピードを重視するあまり、目的を定義しないまま、すぐに実現できるツールや技術といった“手段”を選んでしまうことにあるという。

　「手段は、目的が定義されて初めて価値が生まれる。目的を定義すれば、たとえ1つの手段がうまくいかなくても、複数の代替手段の中からより良い手を選択できる」（日比野氏）

　検討時のポイントは、MECE（漏れなく、ダブりなく）に基づき、手段のメリットとデメリットを検証してバランスを取ること。参考として、同氏は目的を松竹梅に分けて整理する手法を紹介した。

目的に対する手段を松竹梅で整理する（日比野氏の講演資料から引用）

　「効率化や自動化を否定しているのではない」と日比野氏。要は、考える力を失うまで偏らないよう、意識してバランスをとることだ。

　ソフトスキルで挙げられていたもう一つは、俯瞰力だ。ソースコードや詳細設計書、パラメーターシートのような具体的なものと、概要資料やエグゼクティブサマリーといった抽象的なものの双方を行き来できる「バランス力」とも言い換えられる。

　このスキルを身に付けることができれば、「具体的な他社事例を抽象化して本質をつかみ、その上で自社にあった具体的な施策に落とし込むこともできるようになる」と日比野氏は言う。実際、同氏もデータ分析技術をセキュリティ領域に流用する取り組みの中で、俯瞰力を生かしたという。

　「2015年に『Elastic Stack』を、2019年にLookerをセキュリティログ分析基盤に取り入れたとき、セキュリティ製品では耳にすることのない全文検索やBIツールなどをいったん抽象化し、本質を捉えた上で、セキュリティ領域に展開していった。先端技術を異なる領域で応用でき、コスト削減も実現できた」（日比野氏）

データ分析技術のセキュリティ領域への流用（日比野氏の講演資料から引用）

　最後に日比野氏は、「運用改革は意識改革だ」とまとめる。

　「思考停止せず、走り続けながら考えること。技術やツールはあくまでも手段と理解し、本質を捉えて目的にマッチした手段を選ぶこと。そして、視座を高く、全体を俯瞰する力を身に付けること。これらが、結果的に運用管理の品質を高める基礎になるのではないだろうか」（日比野氏）