開発者や DevOps チームの一員の場合、コンテナーとサーバーレスについて、あなたがどちら派であるかといった議論をしたことがあるかもしれません。この記事では、このトピックについて NetApp が主催したディベートを振り返ります。コンテナー側で主張するのは、Spot by NetApp の CTO である Kevin McGrath 氏、サーバーレス側には、A Cloud Guru の Director of Content and Community である Forrest Brazeal 氏がいます。今回の記事では、双方の主な主張を取り上げています。
コンテナーの事例 – 完璧なパッケージ構造
コンテナーが登場する前は、組織は独自の方法でアプリケーションをパッケージ化して配信していました。各チームは独自の言語、ポリシー、パイプラインを持っていて、アプリケーションを本番環境に導入したり、スケールアップしたりするためにカスタマイズされた方法を使っていました。Docker コンテナーの出現により、すべての人が単一の構造を使ってアプリケーションをパッケージ化し、デプロイすることができるようになりました。この構造は、アプリケーションのパッケージ化を定義するのに適しています。どのようなコードでもいかなる要件とライブラリでコンテナーに格納し、他の人がそのコードをどのような環境で実行できるようにすることができます。
同時に、コードの依存性を減らし、コードをサーバー層から切り離すことができました。その結果、OS のようなサーバーへの依存性を気にすることなく、小さなオブジェクト (コンテナー) を開発環境から本番環境へと簡単に移行することができます。コンテナーはゲスト OS をホスト OS から分離し、より良いデカップリングを実現します。また、インスタンスごとに独自のホスト OS を必要とする VM に比べて、より軽量になります。これは大きなパラダイム シフトでした。アプリケーションを提供するための普遍的な方法がようやく手に入ったのです。
オーケストレーションで複雑になったコンテナー
しかし、コンテナーにはバラ色のものばかりではありませんでした。本番環境で大規模にコンテナーを稼働させる方法が必要だったのです。そのためには、コンテナー間のネットワーク、ステートフルなストレージ、セキュリティを扱う新しい方法が必要でした。新たな課題は、このような複雑さにもかかわらず、いかにしてコンテナーを実行するかということでした。
解決策は、Mesos、Docker Swarm、Kubernetes などのコンテナー オーケストレーション ツールを使うことでした。業界が単一のオーケストレーターである Kubernetes に集約されるまで、それほど時間はかかりませんでした。しかし、Kubernetes は、VMware のような伝統的な VM 管理プラットフォームとは運用が異なります。宣言型で、自動化に重点を置き、Istio や Prometheus などのオープンソース ツールに大きく依存しています。これらのことは、Kubernetes が急な学習曲線を持っていたことを意味します (どのように変化したかについては、以下に説明しています)。
サーバーレスはよりシンプルだが、コントロールを犠牲にする
サーバーレスが登場したとき、コンテナーを実行する際の複雑さを解決するように思えました。サーバーレスでは、自分のコードをどなたかに渡して、その人に実行してもらうだけです。これにより複雑さは解消されますが、基盤となるレイヤーのコントロールを失うことになります。依存関係、コールド スタート、カスタム ライブラリ、リソース消費量の制限などをコントロールしようとすると、多くのベンダー固有のカスタム ツールや戦術が必要となり、アプリケーション自体から焦点が外れてしまいます。この意味で、サーバーレスは、ある時点から同じように複雑になるため、ますますコンテナーに似てきます。
そのため、コンテナーをサーバーレスで実装するというハイブリッドなアプローチになりました。コンテナーのサーバーレスから得られた最大のポイントは、『いかにコンテナーをできるだけシンプルに実行できるか』 ということです。とはいえ、やはりコントロールには妥協できません。やはり最高のハードウェア、ネットワーク、ストレージなどへのアクセスが必要であり、これはサーバーレスよりもコンテナーが提供するものと近いものとなります。
シンプルさとコントロール性の両方を兼ね備えた Kubernetes
今日では、コンテナーとコンテナー オーケストレーションは非常に簡易的なものとなりました。Kubernetes は、クラウドにおける事実上のコンテナー オーケストレーターとなっており、その活発なコミュニティのおかげで、管理がより簡単になりました。Kubernetes は、サーバーレス特有の使いやすさを、制御に妥協することなく実現することができます。
とはいえ、コンテナーとサーバーレスのどちらかを選ぶ組織は以下のようなものを問うべきです。
- プラットフォームから得られるユーティリティは何か？
- DevOps チームと運用チームに必要なユーティリティは何か？
- 自社のオペレーション チームはサービス障害に対応できるのか？
1 秒間に何百万ものトランザクションを実行するようになると、パフォーマンスの最適化、コスト効率、アプリケーション レベル以下のすべてが重要になります。サーバーレスでは、コードの実行を他の人に任せていても、デプロイしたすべてのものをサポートする必要があります。サービスがダウンしたときのバックアップ戦略が必要です。簡単に始められるサーバーレスですが、ニーズが増えてくるとオペレーションをシンプルに保つことができなくなります。これは特に大規模な組織に当てはまります。その他にも、ベンダー ロックイン、オープンソース ツールの不足、レガシー アプリケーションよりもモダン アプリケーションに偏るなどのデメリットがあり、コンテナーに軍配が上がります。
コンテナーを利用することで、組織はレガシー アプリケーションとモダン アプリケーションの両方を、DevOps チームとエンジニアが一緒になって迅速に動かすことができます。また、移行したいクラウドやシステムを自由に選択できる柔軟性が得られます。コンテナーにより、アプリケーションを容易に拡張することができます。
もちろん、サーバーレスから学んだことを、可能な限りコンテナー管理に応用することは有効です。しかし、大規模なアプリケーションや大規模な組織にとって、コンテナーは、アプリケーションを本番環境にデプロイする方法や、クラウドを利用する方法を大きく変えました。
コンテナーとサーバーレスのハイブリッドを探しているのであれば、AWS Fargate ではサーバーレス環境でコンテナーを実行できます。もちろん、基盤となるインフラのコントロールは失われ、コストも高くなる可能性があります。もうひとつの選択肢は (Spot by NetAppの) Ocean by Spot です。ハンズフリーでサーバーレスのような体験を提供する一方で、インフラ層を深くコントロールすることができ、劇的なコスト削減とパフォーマンスの保証を実現しています。
サーバーレスの事例 – Own less, build more
サーバーレスについてまず注意すべきことは、コンテナーほど普及していないということです。業界の中には、サーバーレスが使われて大成功を収めているポケットがあります。例えば Amazon では、新規開発の約半分を Lambda で動かしています。しかし、コード シッピングのパラダイムとしてのサーバーレスや FaaS は、一部の人が考えていたような形で世界を席巻しているわけではありません。Lambda は最近、Lambda のパッケージング抽象化として、zip ファイルだけでなくコンテナーをサポートすることを発表しました。
これは、コンテナーがパッケージングの抽象化の戦いに勝利したことを証明しています。しかし、それがすべてではありません。
サーバーレスの考え方は、パッケージの抽象化よりも大きなもので、これこそが今起きている最大のパラダイム シフトです。それは、「own less build more」 と表現される考え方です。DynamoDB、Zapier、Twilio、Auth0、Stripe などのサービスには、こうした考え方の例がたくさんあります。これらのサービスは、組織が独自に管理していたアプリケーションのワークフローの一部を切り離し、組織が利用できるようにすることで、スタックの管理やメンテナンスではなく、本当に重要なものを構築することに集中できるようにしています。
一方、コンテナーの考え方は、10 年前と同じソフトウェアを、クラウドのベスト プラクティスに基づいて新たに構築して提供するというものです。多くのレガシーなユースケースにとっては素晴らしいことですが、最終的には、コンテナーは過去のものを再パッケージ化するものであり、サーバーレスは未来を再構築するものなのです。
サーバーレスが素晴らしい理由として、直感に反した 3 つの理由があります。それぞれを見ていきましょう。
1. サーバーレスは熱力学の第二法則に反する
従来の IT の世界では、一行のコードが本番にデプロイされた時点で、それが崩壊し始めます。競合他社に追いつくためには、コードとその上で動作するハードウェアにエンジニアリングとメンテナンスの時間を常に注ぎ込む必要があります。サーバーレスの考え方は、この IT 物理学の基本法則を逆手に取ったものです。サーバーレスでは、これらのサービスが時間の経過とともに悪化するのではなく、実際に下地が良くなっていくことが可能です。
これは、サーバーレスを利用する何千人ものユーザーのユースケースが集約されているからこそ起こることです。インフラの多くが抽象化されているため、クラウド ベンダーは完全にコントロールすることができ、すべての顧客に利益をもたらす改善を行うことができます。クラウド ベンダーは、さまざまなワークロードに対してパフォーマンスを最適化することができます。それはまるで、優れたハイブマインドがあなたに代わって働いてくれているかのようです。
その好例が AWS の DynamoDB です。サーバーレス データベースである DynamoDB は、以前はプロビジョンド キャパシティと呼ばれる課金モデルで運用されていました。これは、データベースの下にどれだけの計算能力が必要かを見積もって、毎月その能力に対して料金を支払うというものです。その後、AWS は 「DynamoDB on-demand」 と呼ばれる、実際の使用量に応じて支払う新しい課金方法をリリースしました。
しかし、開発環境やステージング環境のように大量のデータを使用しない場合は、DynamoDB のオンデマンド化によって年間数千ドルのコスト削減が可能です。しかも、そのオンデマンド容量にチェックを入れるだけで、エンジニアリングの革新もリファクタリングも必要ありません。サーバーレスの力によって、DynamoDB のテーブルは以前よりもずっと速く、コストをかけずに実行できるようになりました。
2. サーバーレスは高額
サーバーレスは高価ですが、それは特に問題ではありません。その理由は、そこにお金をかける価値があるからです。これは、サービスを稼働させ続けるために必要な、追加でかける時間や頭脳の量に比べるとそこにお金をかけるほうが高い価値を得られます。
開発者には、買うよりも作りたいという傾向があります。例えば、マネージド ロギング サービスではなく、オープン ソースの ELK スタックを使用することなどです。しかし、もし開発者が、ロギングのことを知り尽くしたドメイン スペシャリストが運営するマネージド ロギング サービスを利用することができれば、開発者はビジネスの中核に集中することができます。
お金とエンジニアの時間を効率的にトレードする機会はめったにありません。サーバーレスでは、このトレードオフが以前に比べて非常に簡単になりました。お金を使って時間を確保し、長期的により大きな価値を提供するものを作るチャンスを得ることができます。これは、コンテナーよりもサーバーレスを支持するもう一つの強い理由です。
3. サーバーレスはロックインを伴う
サーバーレスは、ベンダー ロックインやクラウド ロックインを伴います。これは実は良いことで、サーバーレスの大きなセールス ポイントでもあります。
実際のところ、誰もが何かの制約に縛られています。それがプログラミング言語であろうと、アーキテクチャの選択であろうと、ビジネス上の制約であろうと、規制上の制約であろうと、組織は好むと好まざるとにかかわらず、20 年ほど前に行った選択に縛られています。そこで問題となるのは、何に対して制約を縛られるかということです。
AWS IAM は、AWS クラウドで行われるすべての作業を支える、クラウド ロックインの好例です。これは、20年前に企業の認証を支えていた Active Directory に似ています。Active Directory は、誰もが必要とし、サポートしてくれる人材を簡単に見つけることができ、ドキュメントも充実していたため、これらの大企業の文脈では完全に意味をなしていました。
サーバーレスも同様で、クラウドのロックインにもかかわらず、そのクラウド プラットフォーム内のネイティブな統合を深く活用することができます。Lambda 関数やその他のマネージド サービスに接続する多数のトリガーがあります。クラウド プロバイダーは、これらすべてのサービスができるだけ簡単に相互に連携し、うまく機能するようにすることで、組織がより早く移動し、より早く構築できるようにすることに関心があります。
逆に、コンテナーの場合は、ベンダー ロックインを避けることができると思っていても、必ずしもメリットはありません。実際には、コンテナーは複雑で管理が難しく、Kubernetes インスタンスを EKS や AKS、GKE などのマネージド サービスを通じてクラウド プロバイダーの手に戻すことになるため、一種のバックドアロックになってしまうことが多いのです。
これらはすべて、企業がコンテナーのオーケストレーションに対処することを望まず、代わりにクラウド ベンダーにコンテナーを実行させているケースです。しかし、これではポータブルでベンダー ニュートラルなソリューションを実現することはできません。別のクラウド ベンダーに移ろうと思ったときには、移るための高いコストがかかります。前方ではポータビリティのように見えても、バックエンドではクラウド ロックなのです。
サーバーレスの考え方は、所有するものを少なくし、より多くのものを構築することです。
サーバーレスは、自分で管理しないコンピュート上でコードを実行する構造になっているため、本来のビジネスの優位性を追求することができます。関数を書いて、テストして、デプロイして、あとはクラウドに任せればいいのです。
結論
お分かりのように、この議論ではどちらの意見も正しいのです。あなたの組織にとってコンテナーとサーバーレスのどちらが最適かは、拮抗していると言えるでしょう。最後に、この討論会でパネリストを務めた CNCF の Cheryl Hung 氏のコメントで締めくくります。
『2 日目のことを最初から考えなさい。というのも、今日、どちらかの技術に移行するのは実はとても簡単なのですが、2 日目には大きく異なることがあるので、そこを判断する必要があるのです。』
本記事で紹介している Spot Ocean の詳細はこちらから。
パブリック クラウドのコストを最大 80% 削減するクラウド サービス Spot の製品に関する情報はこちらからご覧いただけます。
Spot Ocean または Spot の製品に関するお問い合わせはこちらから。
NetApp が主催したディベートの動画は以下からご覧いただけます。(英語)
参照記事:
The Spot.io blog
Serverless vs. Containers – Which is right for you?
