堅牢で拡張可能なクラウドプラットフォームは、強力なSaaS（Software as a Service）を構築し配布するための基盤である。それは、エンドユーザーのニーズを満たすために特化したサービスを提供するために、迅速に反復できる共通のレイヤーを提供する。
Diagridの創設ソフトウェア・エンジニアであるJoni Collinge氏は、QCon Londonで講演し、DiagridのSaaSを支えるDiagrid Cloudプラットフォームの進化的な設計と実装に関するケーススタディについて議論した。
Google Cloud Platform(GCP)、Azure、Amazon Web Services(AWS)などのクラウドプラットフォームは、セルフサービス、マルチテナント、スケーラビリティ、弾力性などの機能により、SaaSを提供するために不可欠である。これらのプラットフォームにより、開発者は高レベルのコーディングパターンを使用し、アプリケーションを効率的にブートストラップでき、Kubernetes（K8s）、MySQL、Redisなどのテクノロジーに対応するクラウドにとらわれない環境をサポートする。これらのクラウド・サービスを利用する大きな利点は、Diagridモデルに見られるように、マルチクラウド戦略を維持することである。これは、イグレス・コストを管理し、さまざまなリージョン間でデータをポータブルに保つことでコンプライアンスを確保するのに役立つ。
このようなクラウド環境を効果的に管理するためには、コントロール・プレーンの設計が重要である。これには、リソースの公開と管理を合理化するために設計されたCloud API、Cloud Control API、ARM APIを使用した堅牢なAPI戦略の開発が含まれる。Kubernetesリソースモデル（KRM）とOpenTofu やTerraformのようなツールは、構造化されたテンプレートと例を提供することでリソース管理を強化する。Kubernetes Control Plane（KCP）のようなソリューションを通じてセルアーキテクチャと分散制御を採用することで、複雑なマルチプレーンアーキテクチャをサポートするスケーラブルで弾力的な環境を実現できる。REST APIとカスタム制御オプションを統合することで、ユーザーとサービスプロバイダがリソースを効率的かつ柔軟に制御できるようになる。
セッション終了後、InfoQはJoni Collinge氏にインタビューした。
InfoQ: Diagridでエンジニアリングをリードしてきた経験から、現在のユーザーとビジネスのニーズを満たし、将来の要件や技術に適応可能なクラウドプラットフォームの設計にどのように取り組んでいますか？プラットフォームが進化しても拡張性と保守性を維持するために役立った具体的な戦略や設計原則を教えてください。
Joni Collinge氏: 将来のユースケースに対応するために容易に拡張でき、需要の増加をサポートするために進化できるクラウドプラットフォームを構築するのは複雑な作業です。しかし、機械レイヤーをビジネス・ロジックの仕様から意図的に分離した設計にすることで、このプロセスを単純化することができます。データを一般的にどのように構造化し、どのようにプラットフォーム内を移動し、どのタイミングでロジックが動作するかという仕組みを提供する役割を担う機械は、特定の実装の詳細を扱うべきではありません。その代わりに、ビジネスロジックは、特定のユースケースに対応するためのAPIと特殊な処理ロジックを提供するマシンにマッピングされます。このアプローチは、新しいユースケースが発生したときに、既存のマシンの上に新しい実装を導入可能にし、ゼロから始める必要性を排除します。
KubernetesのAPIサーバーは、この分離を実現する優れた例です。その設計により、多くのケースで本来の範囲を超えて使用されるようになっています。しかし、汎用のクラウドAPIサーバーとして直接使用することは、Kubernetesシステムのある種の制約のために困難で非効率的である可能性があります。したがって、私は他の人にその設計を分解し、その拡張性を可能にする創設の原則を理解し、その制約を明らかにすることを勧めます。これらの原則が明確になれば、Kubernetesの限界を超えた拡張可能なクラウドプラットフォームを構築するために、他の場所で似たような特徴を探すことができます。
InfoQ: Kubernetes、Dapr、クラウドネイティブサービスといった抽象化された技術を活用することについて言及されましたが、これらの技術がSaaSのポータビリティと拡張性の実現にどのように貢献しているのか、詳しく教えてください。
Collinge氏: クラウドプラットフォームのホスティング方法と、クラウドプラットフォームが提供するサービスには違いがあります。例えば、Kubernetesの「ような」APIをユーザーに提供してリソースを管理しても、必ずしもKubernetes上でCloud Platformを稼働させる必要はありません。この違いを理解することは、別々に解決できるのに両方の問題を同時に解決しようと制限しないために不可欠です。クラウドプラットフォームをインフラ間でポータブルに保ちたいのであれば、コードはAPIにバインドし、プロバイダーに依存しないランタイム上で実行しなければなりません。どのAPIとランタイムを選択するかは、特定の要件と制約によって決定されます。
しかし、スタートアップ企業としては、マネージド・サービスを活用することで、ホスティング・プロバイダーにできるだけ多くの作業をオフロードすることが一般的に良いアドバイスとなります。我々の場合、これはランタイムにKubernetes、データベースにMySQL、キャッシュとストリーミングにRedisを使うことを意味しました。Daprプロジェクトはまた、あなたのコードを基礎となるインフラから抽象化することで、移植性を犠牲にすることなく、より生産性の高いクラウドAPIにバインドすることを可能にします。例えば、DaprのPub/Sub APIを使えば、コードを変更することなく、RedisやAWSのSQSのような上位のサービスに対して非同期メッセージングを実行できます。
InfoQ: さらに、これらのクラウドネイティブテクノロジーを開発プロセスに統合する際に、特に競争の激しい状況で迅速な適応性を目指す場合に、チームが注意すべき落とし穴や課題はあるのでしょうか？
**Collinge氏:**クラウドネイティブテクノロジーの採用に関して私がもっとも懸念しているのは、複雑さと断片化のレベルの増大です。ほとんどのクラウドネイティブテクノロジーは、説得力のあるユースケースを持っていますが、だからといって、あなたのソリューションにとって必ずしも価値があるとは限りません。新しいテクノロジーの採用は、自社の要件に基づき、デューデリジェンスを行ってその価値を確認した上で行うべきです。ある技術のために別の技術を採用することで、エンジニアに課される精神的な"税金"を過小評価してはなりません。
ビデオ・オンリー・パスでQCon Londonの録画講演にアクセス。