1.1クラウドネイティブってなんだろう？

　本書を手に取った方々は、どこかでクラウドネイティブという言葉を聞いたことがあると思います。端的に言えば、クラウドネイティブとは、クラウド環境に最適化されたアーキテクチャーを指します。従来のオンプレミスのように、サービス要件に合わせてインフラを調達し、個別にカスタマイズするのではなく、AWSやAzure、GCPなどのクラウドサービスが提供するマネージドサービス資源を積極的に活用していきます。クラウドネイティブなOSS技術の推進団体であるCNCF(Cloud Native Computing Foundation)によると、次のように定義¹しています。

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築、および実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および宣言型APIがあります。

これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を、最小限の労力で、頻繁かつ予測どおりに行うことができます。

　つまり、クラウドネイティブなアプローチに従いクラウドリソースを上手く活用することで、従来の環境と比較してサービスを安定稼働させつつも、ユーザーへの影響を最小限にしながら、ビジネスの変化に適応可能なアーキテクチャー構成が期待できそうですね。

　ではなぜ、単純にパブリッククラウドを利用するだけではなく、クラウドネイティブなアプローチがより注目されるようになったのでしょうか？

1.2クラウドネイティブが求められる背景

　レガシーシステム環境からクラウド環境へ移行を考える場合、リフト&シフトという手法がよく採用されます。オンプレミスサーバー群をクラウド上のIaaS(Infrastructure as a Service)環境に移行(リフト)し、猶予期間を設けて安定運用が確認できた後、各クラウドが提供するマネージドサービスに置き換え(シフト)ます。そうすることで、さらなるコスト削減や運用最適化を目指していく、といった流れです。リフト&シフトアプローチは、最初のステップで既存のサーバーをまるごとお引越しするようなイメージに近いです。これには、移行に伴う現行の環境から、OSインフラ構成やアプリケーションの変更を最小限に留められる、というメリットがあります。金融系サービスのような社会インフラシステムに関しては、環境の移行というだけで高いリスクが伴います。そのため、クラウド初期導入を慎重に行いたいビジネスケースなどでは、リフト&シフトは有効な選択肢と言えるでしょう。

　しかし、シフトが完了するまでの間、移行前と同様に、ユーザー自身がOSインフラ構成を運用・管理する必要があります。また、最終的なシフト完了までに、さらなる時間を要します。この移行期間の間に、パブリッククラウド側で新しい機能やサービスが提供された場合でも、クラウドネイティブに最適化されていない場合、なかなか恩恵が受けられないというデメリットもあります。

　ビジネス競争力が必要な場合、OSインフラ側の管理負荷をなるべく最小化し、アプリケーション開発や自分たちのサービス強化の領域に、活動のリソースを集中することが求められます。昨今では、クラウドプロバイダーがOSワークロードや分析、機械学習、IoTといった各分野のマネージドサービスを展開しています。これらの運用自体をクラウド側に移譲することで、アプリケーション開発に注力できることから、はじめからマネージドサービス利用を検討するケースとして、クラウドネイティブなアプローチが注目されています。さらに、クラウドサービスは日々進化しており、クラウドユーザーのニーズに答える形で、サービス利用料の値下げや処理性能の改善、多くの機能が追加されています。マネージドサービスを積極的に採用することで、これらの恩恵を最大限に受けられることでしょう。

1.3クラウドネイティブ化の進め方

　クラウドネイティブな構成にしていくためには、それに適した技術や開発手法、運用等が求められます。また、クラウドネイティブ化には必要なテクニックも多く、一度に全てを理解し適用していこうとすると、学習コストが高くなるのも事実です。

　では、一体どこから手をつけ、クラウドネイティブを進めていけばよいのでしょうか？先ほど、CNCFによるクラウドネイティブの定義をご紹介しましたが、CNCFでは、クラウドネイティブ技術を実践するためのロードマップ²も公開しています。そこでは、最初の一歩として、コンテナ化、CI/CD、オーケストレーションの実践を推奨しています。

　本書でも、このロードマップに従ってコンテナ化、CI/CD、オーケストレーションの技術にスポットを当てます。次に、これらの内容を順番に見ていきましょう。

1.4コンテナがもたらす世界

　コンテナとは、隔離されたCPUやメモリ、ネットワークリソース等の環境下で稼働する、一連のプロセス群です。コンテナエンジンと呼ばれる管理ソフトウェアが稼働する環境であれば、コンテナ化されたアプリケーションを、それぞれ独立的かつ排他的に稼働させることができます。コンテナと対比されるアーキテクチャーとして、仮想マシンで構成されたアプリケーションが、例として挙げられます。ホストOS側からの視点で見ると、コンテナはひとつのプロセス単位で稼働するのに対し、仮想マシンはひとつのゲストOSを単位として稼働します。

　これらの違いが意味するところは何でしょうか？オーバーヘッドと可搬性という、ふたつの観点から見ていきましょう。

　まずは、オーバーヘッドの観点です。仮想マシンは稼働単位がゲストOS単位となります。ゲストOSのサイズはGBオーダーであることが多く、仮想マシン自体の起動に時間を要します。一方、コンテナはプロセスとしてアプリケーションやライブラリが稼働するリソース分のみ確保すればよく、全体のサイズが小さいため、起動時間が早くなります。つまり、仮想マシンと比較して、コンテナは確保するリソースのオーバーヘッドが小さく、アプリケーション起動の高速化とインフラリソースの効率化の観点で、軍配が上がります。

　次に、可搬性の観点から見てみましょう。「可搬性がある」とは、ある環境で開発されたアプリケーションが、他の環境でも同じように動作することを意味します。たとえば、ローカル端末上で開発したアプリケーションが、テスト環境やプロダクション環境で全く同じ動作をするのであれば、そのアプリケーションは可搬性があると言えます。

　仮想マシンでは可搬性がゲストOS単位となりますが、コンテナと比較してサイズが大きく、アプリケーションのリリース単位として見ると、少々運用の手間となります。アプリケーションのみのリリースのために、仮想マシン単位をリリースすることは現実的ではありません。ゲストOS上のアプリケーションのみを再デプロイさせるケースや、AWSで言うとAMIのような、OSイメージテンプレートを更新して起動するケースが多いでしょう。一方、アプリケーションのみ再デプロイする場合、実際のシステムでは、テスト環境やプロダクション環境で、ライブラリバージョンなどのランタイム環境が異なっているケースが多いです。その場合、厳密に稼働保証が担保できないリスクがあります。

　これに対し、コンテナエンジンが稼働する環境では、コンテナ単位で同じように動作することが保証されています。また、仮想マシンと比較して配布可能なサイズ(数MB~数百MB)であることから、コンテナまるごとデプロイさせることが容易なため、可搬性に優れていると言えるでしょう。

　代表的なコンテナエンジンとして、2013年3月にオープンソースとして提供されたDocker³があります。Dockerは軽量かつ導入が容易であることから、多数のクラウドサービス上のコンテナランタイムとして採用されており、現在では多くのコンテナプラットフォームで採用されています。

　コンテナが持つ起動の迅速性と優れた可搬性により、頻繁に変更・リリースを行いたい場合や、即座にスケーリングさせたい場合に、最適な技術のひとつと言えるでしょう。ITリソースを効率的に利用しながら、OS側に依存したアプリケーション動作の不安も払拭されるため、アプリケーションの開発に集中する(ビジネス側により注力できる)ためのキーファクターであると、筆者は考えています。

1.5CI/CDがクラウド時代に求められる理由とは？

　続いてはCI/CDです。CI/CDは技術そのものを表すというよりは、アプリケーションを迅速かつ安定的にリリースするための手法を表します。

　ここで、複数エンジニアでアプリケーションを開発するケースを考えてみます。各エンジニアが開発したアプリケーションを統合する際、最初から期待どおりに動作しない状況を経験された方も多いのではないでしょうか？

　アプリケーションの規模が大きくなると、ソースコードの複雑さはさらに膨らみます。統合する際に複雑な作業を行ったり、ビルド時やテスト時の不具合発生、デグレ(今まで正常に動作していた機能が動作せず、以前より品質が劣化する事象)が発生するリスクも高くなります。開発の後半に不具合やデグレが発生した場合、修正の手戻りも大きくなります。影響が小さい段階で早めに気づき、修正することで、開発リードタイムも短縮できるはずです。また、重要な機能に対する不具合を修正した後などでは、その他の箇所に修正影響が波及していないか確認(デグレ発生有無の確認作業)を行うことも多く、付随するテスト実施の手間も発生するでしょう。このように、アプリケーションの迅速なリリースを行うためには、ビルドやテストを自動化し、早い段階で影響をフィードバックしてくれる仕組みが求められます。

　次に、アプリケーションのテストが完了すると、アプリケーションをプロダクション環境へデプロイさせるフェーズへと進みます。手動でWebアプリケーションのデプロイまでの流れを行う場合、アプリケーションを稼働環境に何らかの方法で持ち込み、内部関係者のみがアクセス可能な状態で、新規アプリケーションをデプロイさせます。事前に稼働確認を行った後、新規アプリケーションから既存アプリケーションの切替を行い、既存アプリケーションを停止させ……といった流れです。手動で行う以上、人的ミスが発生するリスクが、常に伴います。

　また、アプリケーションが複雑になると、稼働環境の資産持ち込みやデプロイ作業自体も複雑になり、職人と呼ばれる人たちがデプロイを行うなど、属人化してしまう例も稀ではありません。属人化を避けるため、膨大な手順書を作成している現場もありますが、先ほどの人的ミスのリスクは存在しており、リリース作業を行うための要員が必要です。デプロイ作業自体にビジネス的な優位性は含まれず、本来であれば誰がやっても同じ流れで実行したいはずです。

　以上のような課題を解決するために、CI/CDという開発手法が生まれました。CI(Continuous Integration)は、開発者が書いたソースコードをリポジトリにマージすることで、ビルドやテストを自動的に実行する開発の手法です。一方、CD(Continuous Delivery)は、プロダクション環境にリリース可能な状態として準備される流れを表し、開発環境やステージング環境への自動デプロイなども含まれます。リリースに向けた一連の手順を決め、それをCI/CDパイプラインという形で定義し実行することで、誰が実施しても、同じ流れのデプロイを実現できます。このCI/CDにより、リリースに対するアジリティが高まることは利点のひとつですが、筆者はリリースに対する心理的ハードルが下がることが、一番のメリットであると考えています。

　パブリッククラウドではマネージドなCI/CDツールが提供されており、CI/CDの流れを実現するためのパイプライン導入が簡単になりました(本書でも、AWSのCodeシリーズを利用してCI/CD環境を構築します)。クラウドを利用するメリットとして、迅速なITリソースを確保できる点があり、それはすなわち迅速なサービス提供へと繋がります。安定したアプリケーションリリースを行い、得られたフィードバックを基に、さらなる改善を継続的に行っていくために、CI/CDはクラウド時代のアプリケーションに必要な要素だと言えそうですね。

1.6コンテナの運用を支えるオーケストレーション

　先ほどご紹介したコンテナですが、複数のホストマシン上に決められたコンテナ数を起動させたり、不具合等によるコンテナダウンを検知して自動復旧させたい場合、Dockerだけでは実現できません。Dockerは、あくまでもホストOSとアプリケーションの間に立って、コンテナエンジンが稼働する環境を提供してくれるものです。実サービスを提供するときに必要な可用性や、耐障害性を提供してくれるものではありません。

　そこで、コンテナ群を制御してくれる仕組みが別途必要となりますが、それを担うのがオーケストレーションです。事実上、コンテナオーケストレーションの覇権を制したKubernetes⁴を、多くの方が耳にしたことがあるのではないでしょうか。オーケストレーションを利用することで、コンテナの稼働管理をより柔軟に行えます。たとえば、オーケストレーションに対してコンテナのデプロイを指示したり、サービスに対するリクエストに対して負荷分散を指示したり、コンテナ間の通信制御やコンテナ障害時の自動復旧などを取り仕切ってくれます。

　オーケストレーションのソフトウェア機能(図1.6)にもよりますが、その他にも、ダウンタイムを避けつつコンテナ間の依存関係を意識しながらデプロイを行ったり、高負荷時にコンテナのスケーリングを制御したり等、柔軟なコンテナ運用を提供します。オーケストレーションツールは非常に多くの機能を有しており、これだけで本1冊書けてしまう程のボリューム感なので、本書ではそこまで深くは述べません。

　一方で、コンテナを利用して、マイクロサービスと呼ばれる比較的小さいアプリケーションが連携してサービスを提供する場合には、多数のコンテナ同士の相互作用や個別のコンテナごとの運用を考慮しなければなりません。コンテナで実運用を検討される場合は、オーケストレーションは必須の技術要素として位置づけ、特徴を理解するようにしてください。

1.7まとめ

　いかがでしたでしょうか。本書を読み進めていく上で重要な知識である、クラウドネイティブの周辺知識を簡単に解説しました。次章からAWSを題材に、より具体的なクラウドネイティブの世界に入り込んでいきます。

2.1構築するサービス図

　本書で構築するサービスは、次のアーキテクチャー図となります。このアーキテクチャーを構築する上で必要なサービスをそれぞれ、「コンテナ」「CI/CD」「運用・監視・セキュリティ」という項目で分類して、順番に説明します。

2.2AWSサービスの紹介 - コンテナ

2.2.1Amazon ECS

　Amazon Elastic Container Service(ECS)は、フルマネージドなコンテナオーケストレーションサービスです。ここでのポイントは、「オーケストレーションサービス」という点であり、コンテナを動かす実行環境のサービスではない、ということです。ECSはKubernetesとは異なり、AWSがオーナーシップを持って進めるコンテナオーケストレーションサービスとなります。2020年1月時点では、Amazon Elastic Kubernetes Service(EKS)もあり、AWSでコンテナオーケストレーションを使うならばECS、とは一概にはいえません。しかし、ECSは以前からあるコンテナオーケストレーションサービスであり、非常に多くの事例と安定性があります。また、ECSは主要なAWSのサービスの基本的柱であるという理由から、他のAWSのサービスとの連携が非常に容易です。信頼性も高く、ECSの月間稼働率は少なくとも99.99％であることが、サービスレベルアグリーメント(SLA)として保証されています。

2.2.2AWS Fargate

　AWS Fargate(Fargate)は、ECSとEKSの両方で動作する、コンテナ向けサーバーレスコンピューティングエンジンです。コンテナを動かすためには、ホストとなるサーバーが必要になります。以前は、このホストにAmazon EC2(EC2)が使われていました。EC2を使う際には、リソースの増強、OSの更新やセキュリティパッチ適用、サーバーが動作しているかどうかの保護や、監視などが必要になります。第1章で、クラウドネイティブが求められる背景として述べたとおり、「ビジネス競争力が必要なサービスでは、OSインフラ側の管理負荷を軽減し、アプリケーションの開発や機能追加に集中すること」が求められます。Fargateでは、ホストの管理が不要となり、これらの要件を満たすことができます。つまり、サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドは発生しません。Fargateでは、コンテナが実行されるインフラは、AWSによって常に最新の状態に保たれます。

　ただし、Fargateも銀の弾丸ではありません。一番に述べられるのは値段面です。執筆時点である2020年1月時点では、かなり安くなってきていますが(こちらの記事¹に記載の通り、大幅に値下げされています)、EC2を使うよりも高いと言われています。ほかにも辛さがありますが、それはあとの章で、じっくりと述べていきます。

2.2.3Amazon ECR

　Amazon Elastic Container Registry(ECR) は、フルマネージドなDockerコンテナレジストリです。このサービスを使うと、Dockerコンテナイメージを簡単に保存、管理できます。また、ECRは簡単にECSと連携することができ、新しいコンテナを立ち上げるときに、簡単にコンテナイメージを取得できます。一般的には、コンテナレジストリはDocker Hub²が使われます。しかし、AWS上でシステムを構築する際は、他のAWSサービスとの連携やセキュリティ設定が簡単なことを考えると、プライベートなコンテナレジストリであるECRを使うことをオススメします。

2.3AWSサービスの紹介 - CI/CD

2.3.1AWS CodeCommit

　AWS CodeCommit(CodeCommit)は、Gitベースのリポジトリをセキュアにホストする、フルマネージドなソース管理サービスです。AWS上で利用できる、プライベートなGitHubサービスというイメージに近いです。Gitベースであるため、通常のGitコマンドをサポートしている点が便利です。CodeCommit利用の最大のメリットは、セキュアな点です。通信中および保管中のファイルが自動的に暗号化されることや、AWSのセキュリティの根幹となるIdentity and Access Management(IAM)を利用した権限設定を、リポジトリに設定できることが強みです。IAMの詳細は、「AWSの薄い本　IAMのマニアックな話」³で詳しく学ぶこともできます。CodeCommitは、AWS上で実現するCI/CD(後述するCodePipeline)のトリガを引く上で、非常に重要なサービスとなっています。

2.3.2AWS CodePipeline

　AWS CodePipeline(CodePipeline)は、フルマネージドなCI/CDを実現するためのワークフローサービスです。ソースコードの変更を検知して、ビルド・テスト・デプロイといったワークフローを自動的に実行することで、高速なCI/CDを可能にします。AWS上におけるCI/CDは、CodePipelineが肝になっています。パイプラインは、ワークフローの論理的な区分として機能する一連のステージ (構築、テスト、デプロイなど) から構成されます。各ステージは、コードの構築またはテスト環境へのデプロイなどのタスクである、連続したアクションで構成されます。CodePipelineを理解するためには、次の用語の理解が不可欠です。

Pipeline

　ビルド、テスト、デプロイなど、ソフトウェアの変更が、リリースプロセスをどのように通過するかを記述するワークフローを指します。

Stage

　リリースプロセスの論理的な作業単位です。ビルドステージ、デプロイステージなど、さまざまな種類のステージを構築可能です。

Action

　Stageの中で定義された、実行されるべきタスクを指します。コード変更によるソースアクション、インスタンスにアプリケーションをデプロイするためのアクションなどが含まれます。

Transition

　あるステージから次のステージへの遷移(トランジション)を指します。ステージに流入してくるトランジションを無効にして、実行がそのステージに入らないように制御したり、そのトランジションを有効にして、実行を継続する、といった使い方もできます。

2.3.3AWS CodeBuild

　AWS CodeBuild(CodeBuild)は、ソースコードをコンパイル、テストを実行、デプロイ可能なソフトウェアパッケージを作成できる、フルマネージドなビルドサービスです。CodeBuildにより、ビルドサーバーのプロビジョニング、管理、スケーリングが不要になります。これが非常にうれしい点です。今までオンプレやEC2でCI/CDを実行してきた人は、ビルドサーバーが落ちる心配や、複数ビルドやテストが走った際のビルドサーバーの高負荷などに、悩まされた経験があるでしょう。CodeBuildはフルマネージドサービスであるため、ビルドのボリュームに応じて、ビルドサーバーが自動的にスケーリングされます。リクエストが送信されると、すぐにビルドが処理され、別のビルドと同時に実行されます。このように、CodeBuildを使うことで、ビジネス的に本質的ではないビルドサーバーやテストサーバーの運用をせずに、CI/CDを実現できます。

2.3.4AWS CodeDeploy

　CI/CDのCode兄弟の最後になります。AWS CodeDeploy(CodeDeploy)は、EC2、Fargateやオンプレミスで実行されるサーバーなど、さまざまなコンピューティングサービスへのソフトウェアのデプロイを自動化する、フルマネージドなサービスです。CodeDeployを利用することで、Blue/Greenデプロイを実現できます。Blue/Greenデプロイの概要と詳細については、後の章で説明します。これによって、新しいアプリケーションをリリースするためのダウンタイムを最小化して、リリースすることが可能になります。CodeDeployのよいところは、以前のリビジョンを再デプロイすることで、すぐにロールバックできる点です。いわゆる、障害による切り戻しの際に利用します。新しいアプリケーションをリリースした後、一定の確認テストを実施したあとに不具合が見つかって、旧アプリケーションに戻す状況は、まれにあります。この戻し作業時は、非常に焦るケースが多く、オペレーションが複雑だと、ミスをする恐れがあります。CodeDeployのロールバック機能を用いることで、シンプルに旧アプリケーションへの戻し作業が可能になります。