こんにちは、株式会社FLINTERSに出向中の佐藤です。
今回はFLINTERSで開催中の企画「梅雨にも負けない！ブログ祭り」として、読書感想の記事を書きました。
読んだ書籍は マルチクラウドネットワークの教科書 耐障害性と冗長性を実現するデザインパターンになります。
私自身 特にネットワークエンジニアというわけではないですが、 友人からこの書籍の紹介を受けて実際に読む経緯に至りました。
この書籍の概要としては実際の販売されているWebページから引用させていただいて、以下のような内容になります。
本書はマルチクラウドにおける、現代的なネットワーク構築・設計を解説する書籍です。ネットワークの観点からマルチクラウドの優位性や課題を紹介します。また、構成例や接続方法はもちろん、デザインパターンや運用方法まで解説します。
また、中身に関してはChapter 1 〜 5で構成されています。
- Chapter1：一般論としてのマルチクラウド
- Chapter2：「ネットワーク」から見たマルチクラウド
- Chapter3：クラウドのネットワークサービスの解説
- Chapter4：マルチクラウドネットワークのデザインパターン
- Chapter5：マルチクラウドネットワークの設計
チャプター別概要
Chapter1
マルチクラウドという概念が今後重要となる中で、Chapter1 ではパブリッククラウドの歴史やマルチクラウド導入に至る変遷とそこに至る各段階で どのようなメリット・デメリットがあるかなどが記載されています。
Chapter2
パブリッククラウドの利用を開始してからマルチクラウドに至るまでのネットワーク基盤を作る意義とそこに行き着くまでのネットワーク基盤の形態について記載されています。
Chapter3
VPCの話やパブリッククラウドとインターネットの関係性、VPCとインターネット間の通信やAWS/ Google Cloud/ Azureにおける専用回線接続やVPN接続について記載されています。
Chapter4
マルチクラウドネットワークに必要となるVPCの通信パターンが記載されています。 ここでは当然マルチクラウド構成するための通信パターンも含まれます。
Chapter5
マルチクラウドネットワークの実際の設計手法が記載されています。 具体的には以下の内容に触れています。
- アドレスアサインやIP設計
- ルーティングの設計について
- 障害事例
- アクセスリストの設計
- NATの設計
- QoS設計
- 暗号化設計
- 拡張性要件
- 運用保守要件
チャプター別印象に残った内容
Chapter1
クラウドサービス選定
前提として、本書で定義されているマルチクラウドは「運営するITシステムに、複数のパブリッククラウドサービス（本書で登場するのはAWS/ Google Cloud/ Azure）を使用すること」と されています。
このマルチクラウドを実際に利用する意図としては、私生活にも影響しているマルチキャリアと同様の考え方です。 過去大規模なパブリッククラウドごとの障害事例を受けて、重要度の高いシステムを複数のクラウドに分散させて耐障害性を高めることを目的としています。
とはいえ切り口として最初にどこかのパブリッククラウドのサービスを利用することから始まると思いますが、本書では主要なクラウドサービスであればどれを選んでも十分な水準にあるだろうということが記載されています。著者である宮川さんの経験では最もシェアが高い有名なサービスを選んだということでした。
実際にシェアが高いサービスであればインターネットに多く情報が落ちているということもありそうですし、私自身の経験ではチーム内で利用候補のサービスからチームで最も知見があるサービスを選ぶこともありました。
AIサービスに関しては得手不得手があるそうなので今後各ベンダー間で競争が激しくなりそうだという考察も書かれていたりしました。
マルチクラウドジャーニーの段階
実際にマルチクラウドを利用するにあたってどんな段階があるかの記載があり参考になったので記載します。
- オンプレミス基盤のみ、クラウド未利用の段階
- シングルクラウド利用の段階
- 複数クラウドを個別に利用する段階
- 複数のクラウドをシステム内の一部機能で併用する段階
- 複数のクラウドに同等の機能を実装して併用する段階
一部の機能をどこかのクラウドサービスに依存する形になるとそのクラウドサービスで障害発生したときに、当然運用ができなくなることは想定できます。 うまく各クラウドサービスで差異なく分割できるかというところは読んでいて重要になる部分かと思いました。
Chapter2
マルチクラウドのメリット・デメリット
マルチクラウドで耐障害性が上がるというのは理解できるものの、デメリットも気になります。 本書ではデメリットとして十分な知見が集まっていないことによる人的および時間的コストの増加や、ネットワーク構成の複雑化が挙げられていました。
Chapter3
パブリッククラウドの捉え方
ビジネス要件としてパブリッククラウドを利用する上で閉域ネットワークを作成できることが当然と私自身捉えていましたが、 本書ではパブリッククラウドはインターネット経由でサービス提供することが前提であり、例外的にVPCでプライベート化されているという意味合いの記載がありました。
AWSではVPC登場以前ではEC2がすべてグローバルIPアドレスを持っていたり、S3の操作もインターネット経由で行っていたということがそれを裏付けているようです。
エンドポイントの脅威
エンドポイントを利用するとネットワークの閉域性を維持したままVPC外リソースを利用できます。 ただし、エンドポイントはAPIへのアクセスを中継するだけで、権限があれば他のアカウントのリソースにもアクセスが可能です。 自社専用のリソースだけを閉じたネットワークになっている訳ではなくセキュリティ上の脅威になり得るということが本書に記載されています。
この場合、機密情報がオブジェクトストレージに存在すると確かに危険な状態です。 基本的に当該エンドポイントを通してアクセスできるリソースを限定できる機能が設定できるようなので設定するのが良さそうです。
異なるクラウド間の接続
異なるクラウド間の相互接続として、AzureとOracle Cloud Infrastructureであれば互いのリソースを連携させることができるようですが、Google CloudではクロスクラウドインターコネクトというAWSやAzureを含む他社クラウドの専用回線接続サービスと直結するサービスを保有しているそうです。もはやマルチクラウドを促すサービスをパブリッククラウド側で展開していることに驚きました。
Chapter4
通信要件
このChapterでは下記の通信要件に対してそれぞれ具体的なデザインパターンを挙げていました。 各パターンで印象に残ったことはありますが、触れていくとかなりのボリュームになるのでこちらは割愛します。
- オンプレミスとVPC間の通信
- オンプレミスとVPC外リソース間の通信
- VPCと同一クラウドのVPC間の通信
- VPCと同一クラウドのVPC外リソース間の通信
- VPCと異なるクラウドのVPC間の通信
- VPCと異なるクラウドのVPC外リソース間の通信
- VPC外リソースと異なるクラウドのVPC外リソース間の通信
- VPCとインターネット間の通信
Chapter5
用途ごとのサブネットの分割
同じブロードキャストドメインではホスト同士が直接相互に通信を行うので、ルーターなどの機器がないと通信制御ができません。 異なる用途をもつ等でお互いに通信する必要がない場合は同じサブネットに接続してはいけないということが本書に記載されていました。
また、オンプレミスのネットワークから見ると要件の異なる仮想サーバ群が同じサブネットにあるので、サブネットを分けていないとフィルタリングの制御が困難であるという内容も記載されていました。 具体的にはオンプレミスでアクセスを許可するシステムと拒否するシステムが同一サブネットにあると、用途別で分けていればサブネット指定で制御できたものが対象システムごとの設定の手間が増えるのでよくないということでした。
QoS設計
ネットワーク基盤におけるQoSは帯域幅の上限だったり、通信の優先度の制御をすることがあたりますが、クラウドでは全体で膨大なネットワークリソースを共有するためあまり考慮しません。 実際に私自身もクラウドサービスを利用するにあたりそこまで考慮したことはないですが、オンプレミスとネットワークを繋ぐ場合にはそうはいかないようです。
VPN接続や専用線接続サービスの接続ロケーションまでのWAN回線には帯域上限があるため、クラウド側と繋げた時にWAN回線側の帯域がボトルネックになる可能性があるということらしいです。
オンプレミスデータセンターと接続ロケーションにQoS制御を行うルーターがある場合はそのルーターでQoS制御を適応できます。オンプレミスデータセンターだけにルーターがある場合にはクラウドからの通信にQoSを適応できないので帯域幅が異なることで大量のロス（クラウド側はポリシリング処理のため）が発生する可能性があります。
IPsec VPNによるVPC接続
各クラウドで提供されているIPsec VPNによるVPC接続は、閉域接続サービスと異なる基盤で提供されているようなのでこちらを利用することで 共通の障害に巻き込まれる可能性は低くなるようです。
また、調達が容易かつランニングコストも低価格なようなので障害時に備えられるサービス特性として適していそうです。
マルチクラウドでも単一障害点はある
マルチクラウドを採用することで可用性は向上しそうですが、通信回線や接続ロケーションは共通する場合が多く、ここが単一障害点になることはあり得るそうです。 通信回線や接続ロケーションを冗長化するにはかなりコストがかかるようなのでマルチクラウドとはいえ、単一障害点を避けられないという点は変わらなそうです。
終わりに
繰り返しですが私自身ネットワークエンジニアではないので、実際にマルチクラウドのネットワーク構成に携わるかどうかは分かりません。 ただ本書によりそこに至るまでのマイルストーンだったり、マルチクラウドを利用するに至る基礎的な知識を分かりやすく学ぶことができたのとても勉強になりました。
