クラウドでのパイプラインの構築
クラウドコンピューティングの出現により、ソフトウェアのホスティングと配布方法が大きく変化しました。 日常的に行われるほとんどのタスクにはオンラインサービスが提供されており、これはショッピングだけでなく、コンピュータインフラストラクチャにおいても変わりません。 この記事では、継続的インテグレーション、デリバリー、およびデプロイメントにおいて、クラウドテクノロジー（特に、infrastructure-as-codeとコンテナ）がどのようなメリットを発揮するのかを確認します。
CI/CDパイプラインのセットアップが初めての方でも、ローカルでホスティングしている既存の環境をお持ちの方でも、これらのテクニックやツールの使い方を理解しておくことで、それぞれのニーズに合ったクラウドテクノロジーを導入することができます。
制限要因としてのインフラストラクチャ
継続的インテグレーションと継続的デプロイメントは、より堅牢なソフトウェアを素早くユーザーにリリースできるように設計されています。
少しずつ頻繁にリリースするアプローチを、ビルド、環境構築、テストの自動化と合わせることで、開発からリリースまでにかかる時間を短縮し、さらに製品の品質に自信を持ってリリースすることができます。
CI/CD ワークフローの後半には通常、エンドツーエンドテストやパフォーマンステスト、さらには手動テストが含まれますが、どれを行うにしても本番環境を十分にミラーしたテスト環境が必要です。 テストの有効性と一貫性を最大限に引き出すには、これらの環境を手動で保守するのではなく、自動的にリフレッシュする必要があります。 そして、こういった作業を実践するには、DevOpsのスキルやツールだけでなく、CIサーバー、ビルドエージェント、テスト環境、およびデータストアに計算能力を割り当てられる大量のインフラストラクチャも必要となります。
ビルドプロセスをサポートするために必要なマシンの数は、プロジェクトの規模や複雑さ、そしてそのプロジェクトに関与する開発者の人数によって異なります。 ただし、その人数も時間の経過とともに変更する可能性があります。
CI/CD パイプラインのインフラストラクチャをホスティングして管理する場合は、要求の高い時期に複数のジョブを同時に実行できる十分な容量を備えることと、長期間アイドル状態となるマシンの購入とメンテナンスに係る費用の折り合いをつける必要があります。 ここで大きなメリットをもたらしてくれるのが、クラウドホスティング型インフラストラクチャです。
クラウドが継続的インテグレーションパイプラインにもたらすメリットとは？
クラウドホスティング型インフラストラクチャの出現により、インフラストラクチャの管理方法が大きく変化しました。
IaaS（Infrastructure as a Service）では、仮想マシン（VM）またはコンテナーによって計算リソースが提供されます。 容量がさらに必要となった場合には、必要な容量をリクエストすれば済むのです（もちろん有料ですが）。調達、インストール、管理、そして物理的なハードウェアのことを心配する必要はありません。
このようにすることで、VMやコンテナーをホストしている実際のマシンに対する（規制や災害普及の目的で地理的なリージョンを知っておく以外の）可視性がまったくなくなるため、意識的な面が大きく変わります。
IaC（Infrastructure as Code）
クラウドホスティングという文脈において、サービスをバックアップするための物理的なリソースを大量に得られることから、サービスを交換可能な使い捨ての商品、いわゆる「家畜」として扱うことができます。 これは、サーバーがペットのように扱われ、固有の名前を付けて、健康状態が不良になれば面倒を見、比較的長い間生存することを期待できた従来のベアメタルのホスティングとは対照的です。
「家畜」のアプローチでは、サーバーに更新または修復が必要となると、そのサーバーは取り除かれて、要件に合う別のサーバーと置き換えられます。 既存のインスタンスを変更したり修復したりするのに、時間や労力を費やすことはなく、 必要に応じてイメージを再構成し、新しいインスタンスをデプロイすることができます。
IaaSでは、使用する計算リソースのみに料金がかかるため、家畜の考え方が適当と言えます。 ここに組み込まれるのが、IaC（Infrastructure as Code）です。 IaCは、インフラストラクチャのプロビジョニングを、スクリプトで繰り返し行えるようにするDevOpsの手法です。
すべての構成情報をコードに組み込んで、アプリケーションコードのようにソースコントロールに格納しておくことで、個別の環境の手動調整により矛盾が生じることを防止することができます。
変更を簡単にロールバックできるというメリットがあるため、開発中のソフトウェアと同様に、インフラストラクチャそのものをCI/CDパイプラインに組み込んで、期待通りに動作することを確認することができます。
インフラストラクチャをコード化することで、環境が必要となれば自動的に作成され、新しい構成がロールアウトされれば自動的に更新されるというように、さらなるオートメーションへの扉が開かれます。
IaaSプロバイダーから共有される計算リソースは実質的に無限であるため、スケールアップとスケールダウンを需要に応じて行える一方で、インスタンスに障害が発生した場合に、直ちに交換することができます。 つまり、CI/CD セットアップは、需要の増加に対応することができ、信頼性の高いサービスを保証することができるのです。
ハードウェアのアウトソーシング
IaaSとCaaSでは、ネットワーキングとストレージ容量の管理を含む物理ハードウェアのメンテナンスやデータセンターのロジスティクスは、サービスの一環としてクラウドプロバイダーが対応します。
このため、チームはパイプラインプロセスの最適化とセキュリティに集中できるようになります。 コストは処理能力と処理時間の要因であるため、長期的により少ないマシン台数が使用される場合よりも素早く成果を得られるように、時間をかけてできるだけタスクを並列化することをお勧めします。
コンテナー
コンテナーはIaCの原理を適用しているため、クラウドホスティング型インフラストラクチャをさらに効果的に使用することができます。 コンテナーはソフトウェアとソフトウェアが実行する上で必要とするすべての依存関係を合わせてパッケージ化しているため、限定されたマシンで実行する状況や構成情報の違いを突き止める作業が無くなります。 Docker は最もよく知られたコンテナーテクノロジーの 1 つですが、他にも選択肢はあります。
コンテナーでは、仮想マシンと同様に、同一の物理サーバー上で複数のアプリケーションを隔離したまま実行することができますが、 VMとは異なり、OSは含まれないため、フットプリントがより小さく、一致したホストリソースの一部を要求しません。 そのため、単一のマシンにVMよりもはるかに多くのコンテナーを持つことができるため、クラウドホスティング型インフラストラクチャに効率的にソフトウェアをデプロイする上で理想的なテクノロジーと言えます。
コンテナーを採用すると、環境上の依存関係と構成情報をソフトウェアとともに単一のアーティファクトにパッケージ化し、それをコンテナーをランタイムで提供するマシンにデプロイできます。
マイクロサービスアーキテクチャと同様に、アプリケーションを複数のコンテナーに分割することも可能で、その場合、分割されたコンテナーは同一のマシンか、ネットラークでクラスタリングされた複数のマシンにデプロイしなければなりません。 大量のコンテナーをより簡単に扱えるように、Kubernetesのようなコンテナーのオーケストレーションツールが開発されており、デプロイメント、管理、スケーリングといったタスクを自動化することができます。
CI/CD ワークフローでコンテナーを使用すると、最新のビルドをパイプラインの様々なステージにデプロイするプロセスがよりシンプルになります。 ビルドアーティファクトはコンテナーのイメージであるため、本番環境にリリースされる前に、各テスト環境に一貫してデプロイすることができます。
CI/CD クラウドパイプラインでは、コンテナーが計算リソースを効果的に使用できるため、自動化ツールを利用することができます。 需要が高い時には容量を増加でき、需要が低い時にはコンテナーを終了して基板のインフラストラクチャを解放することができます。
IaaSのほかに、CaaS（Containers-as-a-Service）も提供するクラウドプロバイダーが増えているため、組織はオーケストレーションプラットフォームを管理してクラスターを構成することなく、直接コンテナーをデプロイすることができます。
クラウド CI ホスティングについて考慮すべき点
CI/CD クラウドパイプラインでは、インフラストラクチャのコスト、拡張性、および信頼性の観点から大きなメリットが得られますが、考慮すべき難点がいくつかあります。
ナレッジとスキル
まず、IaaSやCaaSなどのクラウドサービスを使用するには、学習曲線が伴います。 これらの分野に関わる知識を有していない場合、チームメンバーが時間を取ってスキルを習得するか、外部からその知識を有する人材を得る必要があります。 とは言え、クラウドテクノロジーの対応経験は望ましいスキルであり、チームにそのスキルを開発して最新のテクノロジーを使用できる機会を与えられれば、従業員の定着と雇用の両面でのメリットがあります。
システムアーキテクチャ
マイクロサービス、コンテナー、およびその他のクラウドネイティブの手法を使って開発中のソフトウェアをクラウド向けに設計している場合は、CI/CD クラウドパイプラインでの進捗をコンテナーを使って比較的簡単に自動化することができます。 一方、モノリシックアーキテクチャを使用している場合は、ソフトウェアをコンテナーにパッケージ化するのが課題となるでしょう。
もちろん、コンテナーを必ずしもクラウドホスティング型パイプラインに使用しなければならないということではなく、ビルドを実行するクラウドプロバイダーのインフラストラクチャに仮想マシンを使って、テスト用の一貫した本番前環境を提供することはできますが、 VMはコンテナーよりも多くリソースを消費し、環境を個別に構成する必要があります。
コスト
クラウドでは時間で料金が発生するため、アイドル状態の計算リソースが課金されてしまいます。 クラウドホスティングのコスト効率を高めるには、効率的に使用するしかありません。 つまり、使用状況を監視してタイムアウト期間を過ぎたアイドル状態のインスタンスを解放するツールを活用したり、そのロジックを独自に実装する必要があります。 ロジックを独自に実装するにはそのスキルが必要となるため、ツールの使用やロジックの実装をよく吟味して比較することをお勧めします。
セキュリティ
データやサービスをクラウドでホスティングする際は、セキュリティに関する懸念事項が必ず伴います。 会社によっては、重要なソフトウェアがサードパーティのキットに存在するという考え方だけで、提案が取り消されるでしょう。 とは言え、ソースコントロールリポジトリから、CIサーバーやテスト環境に至るまで、ライブサービスとデプロイメントパイプラインの両方のホスティングにパブリッククラウドを使用している組織もたくさんあります。
リスクを緩和するには、潜在的な攻撃ベクトルを理解し、悪意のある者がパイプラインを使ってライブシステムにアクセスできないようにパイプラインに保護を組み込み、認証管理、テストデータ、およびアクセス制御に関するベストプラクティスを実装することは絶対に欠かせません。
ハイブリッドのアプローチ
IaC、コンテナー、およびコンテナーオーケストレーションはどれもクラウドテクノロジーが起源ではありますが、これらはハイブリッドインフラストラクチャでも使用できます。
これらのツールはプライベートクラウドやオンプレミス型インフラストラクチャでも使用できます。ただし、パイプラインの拡張性には制限があります。 組織で将来的にクラウドホスティング型インフラストラクチャに移行することが計画されている場合は、早いうちにクラウドネイティブのツールを採用しておくことで、あらかじめ専門知識を組み込み、移行作業を楽にすることができます。
クラウドネイティブのIaC手法には、ローカルインフラストラクチャでの継続的インテグレ―ションと継続的デプロイメントに対する様々なメリットがあります。 新しい環境の構成は、スクリプトを実行するだけで行えるため、非常に迅速に行えるようになります。
環境作成をコード化すると、セキュリティ、パフォーマンスまたはUIのテスト、あるいはサポートと営業チーム向けのサンドボックスなど、目的に関係なく、本番環境と本番前環境が同一であることを保証する一貫性を得ることができます。 インフラストラクチャ構成ファイルをソースコントロールに格納しておくことで、いつどのような変更が導入されたかを示す監査証跡を維持できるため、より簡単に環境に関わる課題のデバッグを行えるようになります。
デプロイメントパイプラインの特定のステージでのみクラウドリソースを使用する組織もあります。 たとえば、負荷テストやパフォーマンステストでは大量のリソースが必要となる場合があるため、これらを実施する上では、一時的な環境をクラウドに作成する方がより高いコスト効率を得られるからです。 このアプローチを検討する場合は、ビルドを別のインフラストラクチャに移行する際に伴う潜在的に複雑な作業や時間を考慮することが重要となります。
CI パイプラインにクラウドを選択すべき理由
自動化された CI/CD プロセスには、提供の速度と品質の保証という点で大きなメリットがありますが、速度とスループットにおいてはインフラストラクチャの可用性が制限要因となります。 パイプラインをクラウドに移行すれば、リクエストのピーク時に十分に対応できるサーバーのプロビジョニングと、連続的には使用されないマシンの購入と管理に係るコストを比較して考える必要がなくなります。
クラウドネイティブのテクノロジーと手法を取り入れることで、クラウドホスティング型インフラストラクチャを有効に活用できるだけでなく、継続的インテグレーションと継続的デプロイメントのテクニックをさらに強化することができます。 これと同じ手法はローカルのインフラストラクチャにも適用できるため、ソフトウェアの提供をより素早く確実に行えるようになります。