コンテナがスケーラビリティをどのように変えるか

「クラウドスケール」という言葉は、よく軽々しく使われます。 これは、従来の「それほど大きくはないが、それでも重要な規模」とは対照的に、本当に大きな規模を意味するためにマーケティングでよく使用されます。

しかし、神話や伝説の中に真実の核が隠されているように、「クラウド スケール」という用語の使われ方にも、ある程度の真実が含まれています。

真実は、クラウド、そして今ではコンテナがスケーラビリティの基盤を変えたということです。 この変化は、垂直スケーリング戦略と水平スケーリング戦略の根本的な違いに根ざしています。 21 世紀の最初の 10 年間、私たちは、必要な速度とフィードを実現するには垂直スケールが最善の方法であるという考えに基づいてほぼ独占的に事業を展開してきました。 それは、より多くの帯域幅、より多くのコンピューティング、より多くのメモリを意味しました。 より多くのポート。 密度が高くなります。 処理が高速化されます。

しかし、クラウド時代の到来とともに、焦点は水平スケールに移りました。 帯域幅とコンピューティング能力、処理能力はまださらに必要ですが、そのニーズを分散させる方法を学びました。 さらに多くのハードウェアが必要ですが、単一のモノリシックなエンティティではなく、複数のソースから組み立てるだけです。

ゲームを変えるのは、リソースを集める方法です。 間違いなく、コンテナのおかげでゲームは変わりました。

今日のスケールはコントロール プレーンに依存します。 リソースの起動と廃止に使用される API の速度は、負荷分散サービス自体の速度よりも重要かもしれません。 リソースが数分で起動および廃止される環境では、サービス検出の速度が、利用可能なインスタンスにリクエストを配信する上で非常に重要になります。

Sysdig コンテナ使用状況レポート 2019によると、コンテナの半分以上 (52%) の寿命は 5 分未満です。 

• 22% <= 10 秒 
• 17% <= 1分
• 15% <= 5分

ほぼ半数 (42%) が 201 ～ 500 個のコンテナ インスタンスを運用しています。 精度を維持するために、コントロール プレーンはコンポーネントを頻繁に更新します。 クラウドよりもはるかに頻繁に発生し、モノリシック アプリケーションで見られる頻度よりもはるかに頻繁に発生します。

イングレス コントローラ (負荷分散メカニズム) が更新されて、現在利用可能なリソースのセットが反映される速度が、重要な機能になります。 間違っていると、消費者のリクエストが、もう存在しないリソース、またはまったく異なるサービスをホストしているリソースに送信される可能性があります。 どちらの場合も、リクエストが利用可能なリソースにリダイレクトされるため、結果として応答が長くなります。 消費者は返答を待つ時間が長くなり、代わりに立ち去ることを選択する可能性があります。

これらすべては、コンテナ化された環境に展開されたアプリケーションのスケーラビリティを阻害する要因として、コントロール プレーンの速度を指摘しています。

結局のところ、これはコントロール プレーンの規模が問題になることを意味します。 API の設計が問題です。 API へのリクエストと更新が認証および承認されるメカニズムが問題です。

今日のスケーラビリティに関しては、コントロール プレーンが中心的な役割を果たしています。 堅牢でスケーラブルなコントロール プレーンは、あれば便利なものではありません。 これは今日の RFC 必須事項です。