Well-Architected な CI/CD 環境の選択: AWS環境でのオープンソース

(この記事は、Choosing a Well-Architected CI/CD approach: Open Source on AWSを翻訳したものです。)

イントロダクション

CI/CDプラットフォームを構築する際には、ベースとなる全てのツールについて詳細な情報に基づいた意思決定を行うことが重要です。この投稿では機能要件と非機能要件、価値の最大化のバランスに焦点を当てて各ツールを選択するための基準を評価する方法を模索します。

第一の決断:ソースコード管理

ソースコードは潜在的に最も価値のある資産であるため、ソースコード管理ツールを選択することから始めます。通常これらのツールには資産を保護し、必要なときに組織で使用できるようにするために高度な非機能要件があります。通常これらの要件には、高耐久性、高可用性（HA）、一貫した高スループット、およびロールベースのアクセス制御による強力なセキュリティに対する要求が含まれます。

それと同時にソースコード管理ツールには通常多くの特定の機能要件も含まれます。例えばUI上で共同コードレビューを可能にする機能、自動レビュー、マニュアルレビューを含んだ柔軟で調整可能なマージポリシー、その他の数多くあるツールをすぐに使えるするUIレベルでの統合などです。そしてこれらの統合には、モニタリング、CI、チャット機能、アジャイルでのプロジェクト管理が含まれます。

また多くのチームではソースコード管理ツールを他のCI/CDツールへの入り口として扱っています。彼らはチーム間で共有できるようにし、またDevOpsサイクルを通して1つのコンテキストとユーザーインターフェイス内に留まることを好むかもしれません。実のところ、多くのソースコード管理ツールは単一の UI内からCI/CDワークフローにおける複数のステップをサポートするサービスのスタックです。これはCI/CDプラットフォームを構築するための良い出発点になります。

あなたが最初に決定する必要があることは、コード管理用のオープンソースのソリューションを使用するか、AWS CodeCommitなどのAWSマネージドソリューションを使用するかです。オープンソースのソリューションはこれらに限定されるわけではありませんが、Gerrit,Gitlab,Gogsなどが含まれます。

何を採用するかはオープンソースを通じて提供される柔軟性からチームが得られるメリットと、チームがこれらのソリューションのデプロイと管理方法を支持するかによって左右されます。また、インフラストラクチャと管理するためのコストも考慮する必要があります。

CI/CDプラットフォーム用に独自のプラグインを開発する能力を持つエンジニアリングチームや、オープンソースプロジェクトに貢献するエンジニアリングチームは、オープンソースの柔軟性の観点からオープンソースのソリューションを好むことがよくあります。これは独自のクラウドインフラストラクチャの設計とサポートに長けているチームの場合よく当てはまります。もしあなたのチームがインフラの管理をする必要がないという点(特に可用性、スケーラビリティー、耐久性、セキュリティを重要に感じているなら)に柔軟性よりも価値を感じているのであれば、AWSのマネージドサービスのソリューションはよい選択になるでしょう。

ソースコード管理のソリューション

オープンソースのコード管理ソリューション (Gitlabなど) を選択した場合、次に決めることはどのようにアーキテクチャーを設計するかです。あなたのチームは単一のインスタンスにデプロイしますか？それとも高可用性、耐久性、拡張性を考慮して設計しますか？ 高可用性を備えたGitlabを設計したいチームは次のガイドを使用できます。アマゾンウェブサービス (AWS) へのGitLabのインストール

またAWSのサービス(Amazon RDS, Amazon ElastiCache for RedisやAutoscaling Groups等)を利用することによってセルフマネージドなHAシナリオのインフラストラクチャの管理にかかる負担を軽減できます。

セルフマネージドHAなGitlabのデプロイの概要

第二の決断:継続的インテグレーションのエンジン

CIエンジンの選択によっては選択したCIエンジンの追加機能を活用できる場合があります。Gitlabはソースコード管理はもちろんのこと、Gitlab CIと呼ばれるビルトインのCIツールも提供しています。Gitlab RunnersはCIジョブの実行を担当し、実際のジョブの内容はプロダクトのコードとともにGitlabのリポジトリに保存されます。セキュリティとパフォーマンスの理由から、GitLab RunnersはGitLabのインスタンスとは別のリソースに配置する必要があります。あなたはこれらのリソースを管理することも、またはデプロイ支援とタスクランナーを管理できる AWSサービスのいずれかを使用することもできます。オンデマンドサービスを利用することによって差別化されない重労働を取り除くことができます。これによりコストが最適化され、優れた運用が可能になります。あなたは使用した金額に対して料金を支払い、サービスチームは基盤となるサービスを管理します。

継続的インテグレーションにおけるソリューション

アーキテクチャの例 (下記) では、Gitlab RunnersはAmazon EKSで実行されるコンテナにデプロイされています。チームは管理するインフラストラクチャーが少なく、機能を実装しなくても開発に集中でき、オンデマンドのニーズに最適な方法でリソースをプロビジョニングできます。

コストをさらに最適化するためにEKSノードにEC2スポットインスタンスを使用できます。CIジョブは通常計算量が多く、実行時間が制限されます。ランナーのジョブはほとんど影響を与えることなく別のリソースで簡単に再開できます。これにより障害に対する耐性を持つことができ、またEC2スポットインスタンスの利用は非常に魅力的です。Amazon EKSとスポットインスタンスはGitlabで標準でサポートされています。その結果開発するための統合はなく設定のみが必要です。

Infrastructure as Code のベストプラクティスをサポートするために、ランナーは Helmとともにデプロイされ、Helmチャートとして格納およびバージョン管理されます。CI/CDのプラットフォームに用いるInfrastructure as Codeの情報はTerraformのようなテンプレート自身に保存されます。

GitlabとGitlab CIでのInfrastructure as Codeの概要

第三の決断: コンテナレジストリ

コンテナイメージが利用できない場合、ランナーをデプロイすることはできません。その結果、本番コンテナーレジストリの主な非機能要件には、高可用性、耐久性、透過的なスケーラビリティ、およびセキュリティが含まれる可能性があります。同時にコンテナーレジストリの機能要件は低くなる可能性があります。シンプルな UIと、基本的なフローをサポートするシンプルなAPIがあれば十分かもしれません。マネージドソリューションをお探しのお客様は、OCIに準拠し、Helm チャートをサポートするAmazon ECRを使用できます。

コンテナレジストリーのソリューション

この一連の要件では、オープンソースツールの柔軟性と機能速度は利点を提供しません。自立した高可用性と強化されたセキュリティは、実装時間と長期的な管理においてコストがかかる可能性があります。こちらのダイアグラム(ブログ内の最初の図)に基づいて、AWSマネージドソリューションはコスト面でメリットがあり、管理オーバーヘッドはありません。この場合、AWSでホストされるオープンソースソリューションよりも、AWSマネージドソリューションの方がコンテナレジストリに適しています。この例では、Amazon ECRが選択されています。オープンソースのコンテナレジストリを使用することを好むお客様は、Harborのようなソリューションを検討するかもしれません。

Amazon ECRをGitlab CIと共に用いる場合の概要

その他の考慮事項

CI/CDプラットフォームの主なサービスが選択されたので、その他の重要な考慮事項について大まかに見てみましょう。インフラストラクチャとアプリケーションの両方が監視可能であること、バックアップツールとポリシーが整備されていること、およびセキュリティニーズに対応していることを確認する必要があります。

セキュリティグループの使用を含めセキュリティを強化するためのメカニズムは多数あります。IAMを使用してアクセス許可を細かく制御します。堅牢なポリシーによりリソースの公開を制限しトラフィックのフローを制御できます。資産が CI環境から不適切に流出するのを防ぐためのポリシーを実装します。作業者のシークレットなどの機密データを保護するには転送中および保管中にこれらのアセットを暗号化します。鍵管理の運用上の負担を軽減するためにAWS Key Management Service(AWS KMS)のようなキー管理ソリューションを選択します。自動化で一貫した運用を実行しながら安全でコンプライアンスに準拠したアプリケーションの変更を迅速に提供するにはDevSecOpsを実装します。

Amazon S3は、耐久性、安全性、高可用性を備えています。多くのお客様がEBSレベルのバックアップを保存するのに好ましい選択肢です。Amazon S3はバックアップストアの非機能要件を満たしています。またバージョニングと階層化ストレージクラスもサポートしているためコスト効率も高くなります。

可観測性の要件はアプリケーションレベルの監視の汎用性と柔軟性を重視している場合があります。Amazon CloudWatchを使用してインフラストラクチャをモニタリングしPrometheusなどのオープンソースソリューションを通じて機能を拡張するとよい場合があります。Amazon Managed Service for Prometheus (AMP)を使用するとオープンソースの PrometheusとAWSの両方のサービスの多くの利点を得ることができます。メトリクスのインタラクティブな視覚化のためには多くのお客様はGrafanaのようなオープンソースを選択しており、AWSではAmazon Managed Service for Grafana (AMG)で利用できます。

GitlabとAWSを利用したCI/CDプラットフォームの概要

まとめ

十分な情報に基づいた意思決定を行うことによって価値と、AWS上でGitlabのようなオープンソリューションとAmazon EKSやAmazon ECRなどのAWSマネージドサービスのシナジーを最大化する方法について説明しました。機能要件と非機能要件を満たすオープンソースツールと AWSサービスの適切なバランスを見つけることができ、これらのリソースから得られる価値を最大化するのに役立ちます。

Pete Goldberg, Director of Partnerships at GitLab:「開発プロセスを AWS Well Architected Frameworkに合わせる場合、GitLabはお客様がプロセスを構築および自動化してオペレーショナル・エクセレンスを達成できるようにします。組織全体のコラボレーションを促進するために設計された単一のツールとして、GitLabはグループ間の歴史的な障壁を取り除く自動化されたプロセスを介して、エンジニアリングとオペレーションが一緒になる完全分離オペレーティングモデルに従うようにプロセスを簡素化します。これにより組織はビジネスを推進する新しい機能やアプリケーションを効率的かつ迅速に導入できると同時に、必要なリスク軽減とコンプライアンスを実現できます。運用チームはエンジニアリングチームがアプリケーションコードを保存しているツールと同じツールでインフラストラクチャをコードとして定義し、自動化をCI/CDワークフローにまとめることができるため、企業はコンプライアンスとコントロールを組み込んだままより迅速に動くことができ、組織の透明性を高くできます。GitLabのさまざまな AWSコンピューティングオプション（EC2、Lambda、Fargate、ECS、またはEKS）との統合により、お客様はオペレーショナル・エクセレンスを維持するために必要なコントロールを犠牲にすることなくジョブに最適なタイプのコンピューティングを選択できます。」

翻訳は、ソリューションアーキテクト紙谷が担当しました。原文はこちらです。

本ブログの著者

MikhailはRUS-CISのソリューションアーキテクトです。MikhailはWell-architectedのベストプラクティスとAWSでのDevOps技術を用いてお客様のクラウドジャーニーをサポートします。MikhailはChatOps、AWSでのオープンソース、オペレーショナルエクセレンスの設計原則のファンです。