秋のブログ週間2021の5日目の記事です。
はじめに
こんにちは。TIG DX チームのゆるふわエンジニアの前原です。
私は、企業へのクラウドのアーキテクチャ方針を考えたり、デザイン、構築などの仕事を主にしています。その際によくマルチクラウドの導入をしたい！ という要望を最近受けることが多くなった気がします。そこで本記事では、マルチクラウドを導入するときに何を考えなきゃいけないのかを軽くまとめてみましたので少しでも誰かのお役に立てれば幸いです。
マルチxxについて
サービスを稼働させる環境を構築する際に、IPA が提供している非機能要求グレードを参考にするかと思います。
その中にある可用性をどこまで高めるかといった点でマルチxx構成にするかどうかを判断します。その際にキーワードとなるのが、マルチAZ1、マルチリージョン、マルチクラウド構成です。AZ は、AWS が表現しており、GCP ではゾーンです。
マルチAZ 構成
マルチAZ 構成は、複数のAZ をまたいでシステムの冗長化を図ることができます。
そのため、シングルAZ よりも可用性の高いシステムを構築できます。
マルチリージョン構成
クラウドのリージョン障害が仮に発生した場合はどうでしょう。
この場合、マルチAZ 構成をとっていたとしてもサービスを継続させるのが困難なケースが発生する場合もあります。
そこで複数のリージョンをまたいだマルチリージョン構成です。これによりリージョン障害が発生してもサービスを継続させることができるようになります（実際は、この構成を作るのはとても大変です）
ちなみにですが、マルチリージョンは、DR 対策だけでなくユーザエクスペリエンスの向上も図っているケース（グローバル展開しているサービスなど）もあります。
マルチクラウド構成
マルチクラウド構成は、複数のクラウドを利用する構成です。
この構成を実現するのは、マルチリージョンよりも大変です。それでもなぜマルチクラウド構成を選択するのか、どの辺が難しいのかといった点を書いていきます。
てことで、本題に入っていきます！
マルチクラウドをなぜ選択するのか
よくマルチクラウド構成にすることでベンダーロックインの回避や可用性の向上を図れるということから選択する企業さんもいるかと思います。また、シングルクラウドのみでは要件を満たすことができないという理由から局所的に利用するケースもあります。
このように様々な理由から企業は、マルチクラウド導入の検討を進めています。
マルチクラウドのメリット・デメリット
マルチクラウドのメリット・デメリットについてまとめてます。
メリット
- 信頼性/可用性の向上: 仮に1つのクラウド障害が発生した場合でも他のクラウドでサービスを継続させることが可能となります。
- ベンダーロックインの回避: クラウドベンダーに依存することなく、将来的なインフラの移行方針などが立てやすくなります。
デメリット
- アーキテクチャの複雑性が増す: マルチクラウド間のデータ連携など複雑な構成になります。
- コスト増加: 運用コストやインフラコストが増加するとともに複数クラウドを運用するため、学習コストが増加します。
- セキュリティリスクが上がる: 複数のクラウドを併用して管理するため、セキュリティ基準を満たすべき対象が増加し、セキュリティリスクが上がリます。
マルチクラウドを実現するために考えるべきこと
マルチクラウドを実現するためのアーキテクチャパターンから何を気にすべきかをまとめてみます。
ここでは2つの観点でまとめていますが、実際はもっと色々考える必要があると思っています。
- マルチクラウドを実現するアーキテクチャパターン
- コスト
1. マルチクラウドを実現するためのアーキテクチャパターン
マルチクラウド構成を実現するには、DBへの書き込みが発生する場合の構成をどうするかを考える必要があります。
例えば、AWS とGCP の2つのクラウドを利用していた場合、書き込みを同時（Mutli write pattern）にさせるのか、片側だけ書き込み（Single write pattern）とするのかを考えます（データの一貫性）
- Multi write pattern
- インタークラウドロードバランサ（ILB）2によってクラウドへのリクエストを振り分ける
- 両方のクラウドで書き込みリクエストを受け付ける
- マルチクラウドにおいてのMulti write に対応したDBaaS 環境と連携する
- 各クラウドとDBaaS のVPC peering で接続する
- Single write pattern
- ILB で書き込みリクエストは、片側のクラウドに振り分ける
- 読み込みリクエストは、両方のクラウドに振り分ける
- データのレプリケーションは、レイテンシを意識して専用線経由で行う or クラウド間をVPN で接続する
- 各クラウドのDB は、Cloud SQL やRDS を利用し、インタークラウドフェイルオーバーを実現する
- 仮にマスタがダウンした場合は、インタークラウドフェイルオーバー可能な構成とする
Multi write 構成を実現するための考慮点
- インタークラウドロードバランサ
- 書き込み/読み込みの時や読み込みのリクエストを振り分けられること
- マネージドサービスであること
- SLA やリージョン分散などの考慮
- 仮にILB がダウンした場合の対策を用意する必要がある（例えば、DNS 切り替えでクラウドに直接アクセスさせるなど）
- DNS の配置やTTL の考慮
- アプリをデプロイさせる環境
- サーバレス系のサービス利用は、学習コストとリリース方式の差異が生じるため、運用者などのスキルセットなどを考慮して選択する
- k8s など汎用的に利用できるマネージドサービスを利用する方が良いと考える
- DBaaS 構成
- 連携対象のクラウドに対応していること
- 各クラウド間をVPC peering などで接続できること（レイテンシの考慮も必要）
- インタークラウドレプリケーション、フェイルオーバーに対応していること
Single write 構成を実現するための構成
Single write 構成は、ILB を利用し、リクエストの振り分けをよしなに行う構成以外にもDNS を用いた構成も可能です。
- Single write pattern: 読み込みリクエストは、両方のクラウドに振り分け、書き込みは片側とする構成
- Single write/read pattern: 書き込み/読み込みリクエストを片側のみにリクエストする構成
- Single write pattern（再掲）
- ILB で書き込みリクエストは、片側のクラウドに振り分ける
- 読み込みリクエストは、両方のクラウドに振り分ける
- データのレプリケーションは、レイテンシを意識して専用線経由で行う or クラウド間をVPN で接続する
- 各クラウドのDB は、Cloud SQL やRDS を利用し、インタークラウドフェイルオーバーを実現する
- 仮にマスタがダウンした場合は、インタークラウドフェイルオーバー可能な構成とする
- Single write/read pattern
- 書き込み/読み込みリクエストを片側のクラウド（プライマリ）のみに直接送信する
- 仮にプライマリ側のクラウドがダウンした場合は、インタークラウドフェイルオーバーによってダウンタイムを最小限にする
- リクエストの振り分けは、DNS サーバでコントロールする
Single write 構成を実現するための考慮点
- 各クラウドのDB サーバの考慮点
- クラウド特有のKVS などのサービスの利用などはクラウド間のレプリケーション処理が難しくなるため汎用的なサービス利用を優先的に考える
- 各クラウドのDB 間でインタークラウドフェイルオーバーが実現できるかの検証が必要（レプリケーション先のDB をFQDN で指定し、切り替えが問題ないかなど）
- 専用線を介したレプリケーション時のレイテンシに問題ないか
- DNS サーバ構成の考慮点
- リクエストの振り分けをDNS サーバでコントロールするが、DNSサーバをどこに配置するか考慮が必要
- 各クラウドにDNS のサービスは存在するが、障害時に利用できなくなった場合にどのように切り替えるか
- TTL の考慮
2. マルチクラウド構成を実現するためのコストについて考える
マルチクラウド構成を実現するにはコスト観点を考慮する必要があります。
コスト観点としては、単純なクラウド利用料のコストだけでなく、設計、運用、学習コストなども含めて考えます。これらを鑑みてマルチクラウド構成とするのかシングルクラウド構成にするかを考えると良いと思います。
| 項目 | 内容 |
|---|---|
| サービスコスト | ・クラウドを複数利用するため、単純にコストが2倍以上発生する ・DBaaS やILB を利用するためにSaaS の契約が必要となり、コスト増加 ・各クラウドとデータセンター間を専用線（Dedicated Interconnect やDirect Connect）で接続するためのコストがかかる |
| 設計コスト | ・アーキテクチャが複雑になるため、設計コストの増加 ・クラウド特有のサービスを利用したい場合、マルチクラウドではどのように実現するかを設計する必要がある（例えば、キューサービスやKVS などのサービス利用） ・複数クラウドへのリリース方式を考える必要があるため設計コストが増加する |
| 運用コスト | ・複数クラウド運用となるため、メンテナンスコストの増加 ・複数クラウドのユーザ、ID 管理や、脆弱性チェックなどのセキュリティ管理対象が増えるため、コスト増加 ・ログ、メトリクス監視などの管理を各クラウドで行う場合、コストが増加する（仮にオブザーバビリティ製品を使用する場合も同様） ・複数クラウドの清算処理 |
| 学習コスト | ・複数クラウドの知識を蓄える必要があるため学習コストが増加する ・どちらのクラウドにも精通した人材を確保する必要も出てくるためコストが増加する |
Anthos という選択
マルチクラウド/ハイブリッド構成を実現するためにAnthosを利用するという選択肢もあるかと思います。
そこでざっくりとですが、Anthos 構成にした場合について記載します。
- Anthos GKE on AWS によるマルチクラウド構成
- Anthos GKE on-prem によるハイブリッドクラウド構成
- Anthos GKE on AWS
- マルチクラウドでは、各クラウドで汎用的なサービスを利用することで開発差異を極力なくす構成をとっていたが、Anthos を利用することで一貫性を持った開発や運用を実現することが可能
- AWS のEC2 上にクラスタを自動構築
- モニタリング、ロギングを統合
- Anthos GKE on-prem
- オンプレミスも同様に一貫性を持った開発、運用が可能となる構成
- クラウド側に持っていけない情報などをオンプレミス側に配置するなど柔軟な構成が可能となる
- モニタリング、ロギングを統合
- GCP のコンテナエコシステムとの連携が可能（Cloud Build、GCR など）
まとめ
マルチクラウド構成を実現しようと思うと色々なことを考えないといけないことがわかったかと思います。
もし、マルチクラウド構成を実現したい場合は、まずはシングルクラウドで可用性を高めた構成を構築し、裏で継続的に技術検証を行いながらマルチクラウドにシフトしていく準備を進められたら良いと思っています。
また、マルチクラウドを選択することによってクラウドの恩恵を損なう可能性も念頭に置いて検討するのが良いと思います。
秋のブログ週間2021の5日目でした。ありがとうございました！
参考
マルチクラウド構成を実現するためにもっと知りたいという方は、以下のヤマトHD さんとZOZOテクノロジーズさんの動画と記事を参考にすると良いと思います。
非常に分かりやすくて面白い内容です。