2024年12月、GitLabは「ガートナー ITインフラストラクチャ、オペレーション＆クラウド戦略コンファレンス」に出展しました。このイベントにおいて、ソリューションアーキテクト本部長 大井 雄介が講演いたしましたので、本ブログではその模様をレポートします。
GitLabはインフラチームにも大きな価値を提供できる
講演の主要トピックは、プラットフォームエンジニアリングです。冒頭で大井は、「今回のイベントにはインフラ担当の方が多く参加されていて、このセッションにも多くお越しいただいています。GitLabはアプリ開発担当の方々には良く知られていますが、インフラ担当の皆様にはまだ浸透していないかもしれません。しかし、今日話すのは、インフラ担当の方にこそ、ぜひ聞いていただきたい内容になっています」と会場に語りかけます。
インフラの運用・管理にDevSecOpsを採用するケースは増加しています。SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）やGitOps（DevOpsをインフラ自動化に適用した運用モデル）を実現するために、何らかのツールが必要だという認識が高まったためです。実際に、ソフトウェア開発のプラットフォームであるGitLabをインフラ側にも適用することで、SSoT（Single Source of Truth；信頼できる唯一の情報源）として機能させられることは大きな価値をもたらします。
会場の様子
具体的には、インフラの運用・管理を行うツール群をまたいだSSoTとしてGitLabを利用すると、容易に全体像を把握できます。イシューを積極的に使っていれば、各ツールについて過去の採用から導入、改変の経緯についての詳細をつかむことも可能です。IaC（Infrastructure as Code：インフラ定義ファイル）を管理しておけば、CI/CDパイプラインのバージョンが管理できるため、万一のことがあってもデプロイ手順に合わせてロールバックできるようになります。機器／OS＆ミドルウェアの各種設定ファイルの管理や配布も容易です。
このように、GitLabはDevSecOpsを実現するプラットフォームでありながら、同時にSREやGitOpsなどインフラの運用・管理に活用できるさまざまな機能を備えた統合プラットフォームと言えるのです。
「GitLabは、インフラチームにも大きな価値を提供できるソリューションであると自負しています」（大井）
独立した専任のプラットフォームチームが必要
GitLab合同会社 ソリューションアーキテクト本部 本部長 大井 雄介
エンジニアはソフトウェア開発にあたり、計画、開発、リリースのサイクルを高速に回すことを目指します。コンピュータの登場から今日まで、経営者はエンジニアにそれを求めてきました。
しかし、状況は昔と今では大きく変わりました。かつてのエンジニアはコードを書く能力が第一で、スピーディに高効率なコードを生み出すことが求められていました。そして、美しいコードそのものが、エンジニアの誇りでした。しかしながら、現在はコンテナやAPI、セキュリティなど、コード以外のさまざまな知見が求められています。
現在のエンジニアにとって、コードそのものは理解できれば問題ありません。すでにAIがある程度のコードを生成できますから、それを目的に合わせて修正することで業務効率が向上する状況が生まれているためです。最も重要なのは、コードの“周辺領域”を知ることで迅速に成果を出す能力。中でも、多数のクラウドツールの中からそれぞれの特徴を理解し、比較・検討して最適解を使用することは重要なスキルです。ただ、この状況はエンジニアの認知負荷が大幅に高まるという課題を生みました。実際に、エンジニアの認知負荷はかつての10倍になったとも言われています。
必要な知見は多岐にわたるため、一人でカバーできる範囲は限られます。そのために、プロセスは細分化されてきました。必然的に、チーム内でもサイロ化が進むことになります。この状況におけるひとつの最適化のための解が、「プラットフォーム部分を共通化して切り出し、1つのチームに任せる」というものです。全体最適を果たすことを目指した取り組みで、そのために多くの組織で「プラットフォームチーム」が生まれることになりました。
プラットフォームチームのやるべきことを、上図に示しました。同チームは、各プロジェクトと連携しながら、自動化、セキュリティ、API、およびインフラについて一元的に管理することになります。これは、インフラを構築／保守する専任のプラットフォームチームが必要になるというガートナーの定義するプラットフォームエンジニアリングの考え方に一致します。
プラットフォームチームは、開発チームが生産性高く作業を進めることをサポートします。開発チームの行動を制限しすぎず、一方でリスクの高いツールの使用を許さず、万一の際にはすでにリリースされたアプリケーションであってもすべて検査し、迅速に対処して被害を最小限に抑えます。
プラットフォームチームが正しい方向でプラットフォームエンジニアリングを推進できれば、開発チームが行うインフラ関連作業はほぼゼロになり、開発スピードの向上、開発サイクルの短期化を期待できます。一貫したコンプライアンス／ガバナンスも実現します。最終成果物次第で許容リスク範囲を増減させるなど柔軟な運用を可能にすることで、生産性とリスクのバランスを取りながら、全体最適を図ることができます。
セキュリティでは防災も意識してほしい
ブースで配布された景品
さらに、セキュリティ面においてもプラットフォームエンジニアリングが大きく寄与することが期待されています。経営幹部の多くは、セキュリティと聞くとポリシー策定などの企画部分や、ウイルススキャンなどの運用部分だけに注目しがちです。そのため、多くの企業では企画、運用段階のセキュリティには対応が進んでいます。一方、エンジニアは開発段階にやるべきことがあることを知っています。
たとえば、コードそのものがセキュアであるかどうかを検査しなければなりません。Software Bill of Materials（以下、SBOM：ソフトウェア構成の部品表）を実装し、OSSのソフトウェア・サプライチェーンを可視化し、リスクに備える必要があります。定期検査のプロセスは効率化したいですし、脆弱性発見時の即時検査を行える体制を整えておく必要もあります。外注先の管理も必須で、開発チームとプラットフォームチームにかかわるすべての人に共通するSSoTを備えておくことができれば理想です。
大井は、「企画・運用におけるセキュリティを重視すると、主に“減災”を目指すことになります。確かに減災は必要で、SIEMやSOARは有益なソリューションなのですが、 できれば“防災”も目指したいところです。セキュリティ用語を使えば、サイバー・レジリエンスとともに、サイバー・ハイジーンを追求したいのです」と話します。
DevSecOpsでは、ソフトウェア開発プロセスの早期からセキュリティに取り組むことをシフトレフトと呼び、それを重視しています。つまり、開発段階から防災を意識することになり、DevSecOpsの先進企業はこぞってシフトレフトしています。GitLabでは、数多くのセキュリティスキャン機能を用意し、これらを開発プラットフォームに組み込んでいます。同時に、品質を安定させるガイドラインやポリシーをプロセスに適用できるため、規定どおりに各メンバーが仕事を進めながら防災を目指したソフトウェア開発を徹底することができます。
もちろん、減災を無視してよいわけではありません。開発時にリスクゼロだった依存先OSSでも、リリース後に脆弱性が発見されるケースはあります。こうした際には、SBOMを使って完璧に可視化しておき、リスク別に見分けられるビューも提供しています。
優れたプラットフォームチームがプラットフォームエンジニアリングを推進し、GitLabを活用すれば、さらなる価値を得ることもできます。GitLabを開発チームに提供することで得られる多くのメリットもあります。採用したエンジニアは、GitLabの使い方さえ覚えれば、すぐに仕事に慣れて戦力化します。AIを使った生産性の高い開発も可能で、すでにコードの提案機能に対応する言語は25以上になりました。自社が所有するAIモデルとの接続も可能で、社内ポリシーでインターネット経由でのAIサービス利用が制限されているケースにも対応できます。
大井は、「GitLabを全社の共通プラットフォームとして活用することで、インフラチームと開発チームが一体となって仕事を進め、プラットフォームエンジニアリングの浸透を加速することができます」と話して講演を締めくくりました。
書籍