コンテナ化がカギとなるこれからのインフラストラクチャ

今日、ほとんどの技術系企業やスタートアップ企業がクラウドで運用していますが、その多くがクラウドのすべてのメリットをまだ手にしていません。クラウドで Kubernetes を使用していない場合、おそらく独自のソリューションを活用しつつ、独自の補完カスタムツールを作成および保守しているでしょう。また、効率面で多くを棚上げし、フル活用されていない仮想マシン（VM）でワークロードを実行して自らをロックインしている可能性があります。

お客様は現在、仮想マシンの管理とパッチの適用にいくつのツールを使用しているでしょうか。 アプリケーションをどのようにアップグレードしていますか。また、仮想マシンの使用率はどうでしょうか。 今あるものが、すべて効率的であるとは限りません。 仮想マシンのアーキテクチャの脆弱性による障害（サービスの停止、スケーラビリティの問題など）が発生していたり、費用が制御できないという悪循環に陥っていたりするかもしれません。または、ビジネスで求められる次のようなものにインフラストラクチャの設定が対応していないかもしれません。

• MVP をスケーラブルなソリューションにリファクタリング / 再構築する
• 規制または顧客の要望に対応するためにクラウド プロバイダを追加する
• レイテンシを低減して広範な顧客ベースのエクスペリエンスを向上させるために、地理的に拡大する
• エンドツーエンドのセキュリティ対策を改善する
• カスタマー エクスペリエンスの向上（例: サービスの可用性）

過去の負の遺産や技術的負担は、ビジネスを失速させることがあります。Kubernetes への移行が急速に進んでいるのはこのためです。 マネージド コンテナで構成される最新アーキテクチャなら、信頼性と安全性の高いインフラストラクチャの運用を可能にする実証されたパターンが手に入ります。 これにより、安定性とセキュリティを犠牲にすることなく、製品化までの時間を短縮して生産性を向上できます。さらに、イノベーションに取り組む最高の技術人材を獲得できます。

また、今日の業界標準やベスト プラクティスを定義する安定したイノベーションを持つ Kubernetes コミュニティとその周辺のエコシステムから締め出されることを懸念する必要があります。 最終的に、これは最近の雇用問題を考えるとさらに重要なことですが、エンジニアの時間をどこに費やすかを決めなければなりません。インフラストラクチャの維持やカスタムツールの構築と維持、あるいはビジネスを前進させるための優先事項の確認などです。現状に問題は見当たらないとしても、現在のロードマップに技術的負担の解消や以下に関するプラットフォームのギャップの解消なども含まれているかもしれません。

• エンドツーエンドの暗号化
• オブザーバビリティ（ログ、指標、自動ロギング）
• ポリシーの管理と適用
• 高可用性と自動フェイルオーバー
• コスト削減

Kubernetes はオープンソースでプラットフォームに依存せず、一般的なツールがすぐに使用可能であるため、ビルドとデプロイのライフサイクルにおける各ステージでセキュリティとスピードを確保できます。 ほとんどのシステム管理者が時間をかけてまとめるようなあらゆる bash スクリプトとベスト プラクティスの総合体で、API の宣言型セットの背後にあるシステムとして提供されます。 すべてが自動化されており、詳細は表示されず、すぐに使用できます。 Kubernetes は大多数の Infrastructure as Code を排除して、プラットフォームを Infrastructure as Data に代えることができます。コードの記述や保守は不要で、求めるものを Kubernetes にリクエストするだけです。何をすべきかという指示は不要です。これにより、管理オーバーヘッドの時間が大きく節約されます。

従来のワークロードを実行したい場合は、Kubernetes を使用してアプリを仮想マシンから分離し、コンテナに入れることで最新のプラットフォームで実行できます。 ソフトウェアのパッケージにコンテナ イメージを採用することで、仮想マシンのアップグレードを容易にできます。 仮想マシンのライフサイクル管理とアプリケーションのライフサイクル管理を切り離し、Ruby、Python、Java といったものをすべて削除して、仮想マシンを簡素化できるようになりました。そして、それを本来の場所、つまりデベロッパーのアプリケーションの隣に移動させることで、すべてを一か所でコントロールでき、マシンをベアメタルに保つことができます。

マネージド コンピューティング プラットフォームによりクラウドサービスを Platform as a Service に変えて、コンテナのパワーと柔軟性、さらにサーバーレスの利便性を提供します。サーバー、クラスタ構成、メンテナンスが不要なため、コントロールを維持しながら多くの利益を得ることができます。

クラスタ構成にそれほど制御を必要としないワークロードの場合、ノードやノードプールを含むクラスタの基盤となるインフラストラクチャのプロビジョニングと管理をサービスに任せることができます。料金はクラスタではなく、ワークロードにのみ発生します。 このような方法で、セキュリティを最適化し、高額になりうる費用を削減しつつ、クラスタ管理を不要にします。

クラウドネイティブのアプリケーションの場合、サーバーレスが同じことをより少ない作業で実現し、基盤となるインフラストラクチャ管理が不要で、アプリケーションやデータに加えて分析も提供するエンドツーエンドのホストとして機能します。 サーバーレス プラットフォームを利用すれば、複雑さを最小限に抑え、セキュリティ、パフォーマンス、スケーラビリティ、ベスト プラクティスを組み込んだフルマネージド型の環境でコンテナの実行を開始できます。

ここでは、ビジネスへの潜在的な影響と、効率化曲線の先を行くための方法について説明します。

企業によっては、複数のクラウドで運用することが必要な場合もあります。 データ グラビティは現実のものであり、グローバルな顧客ベースを持つ企業は、必然的に、実際にデータが存在する場所の近くにコンピューティングを置いて、レイテンシとネットワーク料金を最小化したいと考える顧客にサービスを提供します。

このような場合、マルチクラウドによって、対応可能な市場を拡大できます。マネージド サービスやデータは他のプロバイダでサポートします。 また、リスク軽減のためにマルチクラウドを重視する企業もあります。いずれの場合でも、マルチクラウドを正しく導入することが重要であり、業界標準のソリューションがその助けとなります。

第 1 に、ワークフローをできるだけ多く再活用し、業務を遂行できるようにします。ワークフローとは、データベースとコンピューティング間のデータフロー アーキテクチャを作成するためのタスク自動化を可能にすることを意味します。 そこで、オープンソースが重要になります。オープンでないデータベースを選択すると、データフロー アーキテクチャや自動化の実装に苦労することになります。 Postgres プロトコル（Cloud Spanner など）や任意のクラウド プロバイダのマネージド Postgres データベース （Cloud SQL など）のようなものを利用する方が好ましいです。

第 2 に、コンピューティングでは、Kubernetes によってデプロイと自動化にかかる時間が大幅に短縮されるため、一連のテクノロジーを選択する際には、プロバイダが設定した境界を越えて動作することを確認する必要があります。境界線は、異なるリージョンやゾーン、異なるプロジェクトやアカウント、さらにはオンプレミスやクラウドである可能性もあります。クラウド プロバイダごとに（AWS、Google、Azure など）別々のインフラストラクチャを構築し、維持するのは時間の無駄です。エンジニアは、それぞれを等しく保つために奮闘することになるでしょう。 一度構築したものを複数のクラウドにデプロイすれば、アップデートが必要なときも一元的かつ一貫して行うことができます。 Kubernetes のようなコンピューティング スタックは、効率的で、新しいクラウド プロバイダを導入するたびに一からやり直す必要のない方法でマルチクラウドを実現することを真剣に検討しているお客様にとって、大きな利点となります。

第 3に、リスク管理です。別の環境でスタックを実行する能力を持つことは、クラウド プロバイダがダウンしたり、お客様のビジネスと競合するリスクを軽減するのに役立ちます。 規制を遵守するために、企業はビジネスの継続性を確保するためのプロバイダを選びます。 例えば、あるリージョンの業務が停止しても、バックアップ プロバイダがあればダウンタイムが発生することはありません。

マルチクラウドへの移行が成功する傾向があるのは、オープン スタンダードを活用した場合です。 たとえば Kubernetes は、アプリケーションの実行、設定、デプロイ、セキュリティ ポリシーやネットワーキングなどの統合の両方において、プロバイダに依存しない API を提供しています。 Kubernetes をマルチクラウドのオペレーティング システムと考えると、一度抽象化のレイヤにすると、ほとんどの主要なクラウド プロバイダ間の違いを非表示にできます。

Kubernetes を使用する場合、選択肢があります。間違いなくご自身で実行できます。Kubernetes はオープンソースのプロジェクトなので、ダウンロードして、クラウド プロバイダや好みの環境に何年もかけてインテグレーションできます。

しかし、これが最善の時間の使い方ではないと判断した場合、マネージド Kubernetes のサービスを利用できます。 AWS であれば、EKS ということになります。 Azure であれば、AKS ということになります。 Google Cloud を利用している場合は、Google Kubernetes Engine（GKE）を意味します。これらのオプションはすべて、共通の Kubernetes API を提供するため、チームがツールやワークフローを構築する際に、さまざまなプロバイダ間で再利用できます。

しかし、すべてのマネージド サービスが同じように作られているわけではありません。 Kubernetes は、稼働しているインフラストラクチャの良し悪しに依存します。GKE は、成熟した、フルマネージド Kubernetes オーケストレーション サービスとして、ギャップを埋めることができます。 同程度の汎用商品¹よりも価格性能比が 42% 高い Tau VM の VM プロビジョニングから、複数のゾーンやアップグレードにまたがる自動スケーリング、GPU や機械学習用 TPU、ストレージ ボリューム、オンデマンドのセキュリティ認証情報の作成と管理に至るまでの、完全に統合された IaaS を提供します。アプリケーションをコンテナに入れ、ニーズに合わせてシステムを選択します。

仮想マシンのクラウド プロバイダとして AWS を選択した場合はどうですか。 EKS にこだわる必要はありますか？大まかに言えば、Kubernetes はすべてのクラウド プロバイダで平等で、Kubernetes API に行き着くことになります。 しかし、API の下には、クラスタ、ワーカーノード、セキュリティ ポリシーなど、あらゆるものが存在します。これが GKE の優れているところです。

引き続き他のクラスタが必要な場合、GKE Connect に接続することで、すべてのクラスタの管理、表示、トラブルシューティング、デバッグを単一の場所で行うことができ、認証情報などの管理も一元的に行うことができるようになります。GKE は、コントロール プレーンやマルチリージョン、マルチゾーンの高可用性だけでなく、エンドツーエンドの管理性により、最高品質の Kubernetes と言えます。 また、GKE は、一元管理されたマルチクラスタ Ingress を使用して、複数のクラスタや複数のリージョンにわたってグローバルなロードバランサを活用できます。

Kubernetes API は使いたいけれども、クラスタのプロビジョニング、スケーリング、アップグレードの責任は負いたくないという場合はどうすればよいでしょうか？ 大半のワークロードでは、GKE Autopilot がノードやノードプールを含むクラスタの基盤となるインフラストラクチャを抽象化し、ワークロードの料金のみを支払います。GKE Autopilot は、強力なセキュリティ デフォルトを備えた標準的な Kubernetes API を提供することで、クラスタではなくワークロードに集中できるようにすることを目的としています。

__________________________

¹ 結果は、他の 2 つの主要なクラウド ベンダーの本番環境 VM と、ベンダー推奨のコンパイラを使用した本番前環境の Google Cloud Tau VM で実行された SPECrate®2017_int_base の推定に基づいています。SPECrate は Standard Performance Evaluation Corporation の商標です。詳しくは、www.spec.org. をご覧ください。

Kubernetes は、組織を仮想マシンから新しい抽象化セットへと移行させ、オペレーションを自動化し、アプリケーションに集中することを可能にします。 しかし、より特殊なワークロード（ウェブやモバイルアプリ、REST API のバックエンド、データ処理、ワークフローの自動化など）については、サーバーレス モデルを活用することで、さらに簡素化されデプロイも最適化されます。

AWS Lambda は、サービスとして関数を書き、あらゆるイベントに接続することができる人気のサーバーレス プラットフォームです。もしかしたらお使いかもしれません。 しかし、データベースに接続してセキュリティに関する懸念に対処することになるため、これらの関数は複雑化する傾向にあり、実際に通常のアプリケーションよりも大規模なものもあります。 では、Functions as a Service のシンプルさを超えたアプリケーションや、既存のアプリケーションをサーバーレスで運用したい場合はどうすればよいでしょうか？

アプリケーションの書き換えが必要な従来のサーバーレス プラットフォームとは異なり、Cloud Run は、既存のコンテナ化されたアプリケーションへの投資を再利用するためのアプローチを提供します。GKE はマネージド サービスですが、どのゾーンで実行するか、ログをどこに保存するか、異なるバージョンのアプリケーション間のトラフィックをどう管理するか、登録ドメイン名、SSL 証明書の管理など、いくつかの重要な決定をしなければならないことに変わりはありません。

Cloud Run では、こうした決定をすべて排除し、従来のワークロードを実行し、ゼロへのスケーリングを完全に無効にすることでコールド スタートを回避できます。 アプリケーションが常に稼働していなければならない場合、Cloud Run は、NFS、WebSocket、VPC インテグレーションなどの従来の要件とともに、それもサポートしています。 しかし、従来の多くのサーバーレス プラットフォームと同様に、Cloud Run は独自で、ビルトインのトラフィック管理や自動スケーリングなどの機能を提供しています。

コンテナをまったく使っていなくて、何から始めればいいのか悩んでいるとします。 ここでは、コンテナ化を採用するための現実的な方法を説明します。

コンテナを採用する 1 つ目の理由は、パッケージ化問題の解決です。今日、再現可能なアーティファクトを作成し、ソフトウェアの中身を理解すること、つまり業界で言うところの安全なソフトウェア サプライ チェーンに関して、多くの取り組みが行われています。そのためには、アプリケーションのコードやランタイム、それらの依存関係を保持するコンテナ イメージを活用することが理想的だと考えています。コンテナの利点の一つは、仮想マシンにデプロイできることです。これにより、マシン全体へのソフトウェアのデプロイと保守の複雑さを軽減できます。

コンテナを採用する 2 つ目の理由は、オーケストレーションです。仮想マシンの管理には、膨大な管理やメンテナンスのオーバーヘッドが発生します。 多くの企業がそうであるように、インフラストラクチャを管理するためにチームは何十、何百ものステップを実行しています。たとえそれらのステップが自動化されていたとしても、自動化ツールは継続的にメンテナンスを必要とします。 また、Terraform、Puppet、Chef、Ansible などの業界標準の自動化ツールを使用していることが前提です。 自作ツールやカスタムツールの場合、メンテナンスのオーバーヘッドはさらに深刻です。

コンテナを採用する 3 つ目の理由は、効率性です。メンテナンスの負担に加え、大多数の組織では、メモリやストレージはもちろんのこと、CPU 使用率も 5〜10% にしか達しません。無駄なリソースが多くあります。 多くのチームは、このギャップを埋めるために、自動スケーリングやビン パッキングなどを実装したカスタムツールをさらに構築し、操作時間をさらに浪費しています。 そのため、クラウドを使いすぎてしまい、料金が驚くほど高くついてしまいます。

自社でオーケストレーション プラットフォームを適切に構築できる組織はほとんどありません。そのため、Kubernetes、Mesos、Nomad などのオープンソース プラットフォームを活用するのが一般的な選択となります。 しかし、メンテナンスの軽減、業界標準のベスト プラクティス、クラウド プロバイダの他の部分との深いインテグレーションといったメリットを実現するためのプラットフォームを求める場合は、コンテナの潜在価値を最大限に引き出すために、GKE のようなマネージド サービスを利用したいと思うことでしょう。

この時点で、「コンテナへの移行は、本当に価値のないダウンタイムになるのだろうか」と思われるかもしれません。最後の手段は、今後の開発の一時停止ボタンを押すことですよね？

その答えとして、これまでのクラウドの経験を生かした正しい方法を説明します。

アプリケーションを仮想マシンからコンテナに移行することは、困難なことのように思えるかもしれません。すべてのコンピューティングを新しいクラウド プロバイダに移行することを意味する場合は特にそうです。 しかし実際には、大幅な変更は不要で、一度に 1 つのアプリケーションから作業できます。仮想マシンから始めて 1 つまたは 2 つのアプリケーションを Kubernetes に移行し、同じネットワーク上で並行して動作させ、仮想マシンと通信させることができます。 すべてを移行する必要はなく、ゆっくり移行していけば問題ありません。

Kubernetes の恩恵をほとんど受けられない大規模で重いデータベースなど、一部のアプリケーションでは仮想マシンのままでいることが理にかなっているかもしれません。 混在していても問題ありません。 しかし、私たちが見てきたのは、ほとんどのお客様が、アプリケーションやオープンソース プロジェクトを Kubernetes の環境に移行することで、多くの利点を得ているということです。 GKE に移行することで最大のリターンを得られるアプリケーションを優先してください。一度にすべてを移行する必要はありません。

Kubernetes は現在も、おそらくお客様がご使用中のと同じ Linux VM 上で動作しています。 自作のスクリプトや自動化のコレクションではなく、インフラストラクチャのロードマップにあるべき多くのものを取り入れた、より合理的で一貫性のあるワークフローを手に入れることができます。 また、Kubernetes のような業界標準のツールを使う場合、新しいチームメンバーのオンボーディングも非常に簡単になります。そうしない場合は、会社独自の方法をすべて教える必要があります。

この時点で、コンテナをゆっくりと、しかし現実的に採用するための道筋が見えてきます。こうして、管理のオーバーヘッドという点ではチームの時間を節約し、コンピューティング コストという点では会社の資金を節約できます。

コンテナやクラウドへの移行については、Kubernetes を全面的に使用していてより良いサービスを探している場合や、既存のアプリケーションやロードマップに合った別のアプローチを求めている場合など、ここで何度もお話ししてきました。

アプリ開発経路がどのようなものであれ、マネージド コンテナ オプションはインフラストラクチャのコストを最小限に抑え、お客様のチームが優れたプロダクトの構築に最大限集中できるようにします。 これからのインフラストラクチャはコンテナ化です。 今こそ、エンジニアとビジネスを成功に導くための準備をするときです。

Kubernetes からクラウド ネイティブへ: GKE での開発に向けた歩みを加速させる

クラウドにおけるコンテナ - アプリケーション開発とデプロイの新しいスタイル

Eric Brewer による Kubernetes の過去、現在、未来

クラウド ネイティブへの再構築: デベロッパーの生産性を大幅に向上させる革新的なアプローチ