Google Cloud の Professional Cloud Architect が気になっている、とこないだの記事で書いたのだけど、プラットフォームに依らないような、「クラウドの特徴や利点、活用方法」みたいなところのおさらいをしたくて、タイトルの「Amazon Web Servicesクラウドデザインパターン設計ガイド」を買って読んでみた。
「プラットフォームに依らない」って、AWSの本やないかい！って感じなのだけど、メジャーどころのクラウドプラットフォームの各クラウドサービスは、細かい差異はあれど各製品に期待されるパーツとしての働きはほとんど似通ってるよな、と、これもこないだの記事をまとめる過程で感じていたので、そこはあまり気にせず、この本で再確認することにしてみた。この本だけで57個もの "クラウドデザインパターン" がまとめられていて便利。
自分的に虚を突かれたクラウドデザインパターン
本書を読みながら、個人的に「オッ」となったクラウドデザインパターンを、復習も兼ねて列挙しておく。
Floating IPパターン
- IPアドレスの別インスタンスへの動的な移動
- DNS Aレコードで指定しているアドレスの変更ではない！（TTLに影響されない）
- 以下のような作業により実現する。
- 静的なIPアドレスを発行しておき、既存のインスタンスにはそれが付与されているものとする。
- 新規インスタンスを用意したのちに、既存インスタンスの静的IPアドレスをデタッチ・新規インスタンスにアタッチすることで、サービス提供する仮想サーバーを切り替えることが可能。
- 万が一新サーバーで不慮の事態が発生した場合でも、即座に静的IPアドレスをアタッチしなおすことで復旧可能。
- 以下の点については注意する。
- VPCではサブネットを超えてアドレスをアタッチしなおすことはできない。
Routing-Based HAパターン
- セグメント（サブネット）やデータセンターを超えたサーバーへのフェイルオーバーとして、ルートテーブルの動的な変更により接続先の透過的な切り替えを実現する。
- DNSを用いた名前解決での切り替えでは、ダウンタイムをTTLより短くすることはできない。
- 冗長化したインスタンスの「自分宛の通信以外を受け入れるかどうかのチェックをおこなうオプション」を無効にすることとの組み合わせでもある。
Write Proxyパターン
- クライアントから各種クラウドストレージに直接データを転送するのではなく、一度仮想サーバーでデータを受け、その仮想サーバーからクラウドストレージに転送する。
- 通常、仮想サーバーとクラウドストレージは特定条件下（例えば同一リージョン内）においては専用線で接続されているため、トータルの転送時間を短くすることができる
- さらに、マルチパーツアップロードという方法を選択する方法もある
- クライアントから仮想サーバーへの転送に、HTTPよりも高速なプロトコル（UDPなど）を使うことができる
- 小さいファイルが大量にある場合には、アーカイブしたデータを仮想サーバーに送り、仮想サーバーで展開したあとにクラウドストレージに転送することもできる
- 通常、仮想サーバーとクラウドストレージは特定条件下（例えば同一リージョン内）においては専用線で接続されているため、トータルの転送時間を短くすることができる
- 以下の点については注意する。
- 仮想サーバー（にアタッチされているブロックストレージ）への書き込み速度がボトルネックとなる場合があるため、必要に応じてディスクをストライピングする。
- インスタンスタイプが低い場合にはネットワーク帯域も細くなる。
Direct Object Uploadパターン
- クライアントからのデータのアップロードを直接オブジェクトストレージに対しておこなわせるパターン。これにより、アップロード処理による負荷を考慮する必要がなくなる。
Cloud DIパターン
- 新規インスタンスのセットアップの際、DB接続先やサーバー名、認識番号といった、変更が多い故に外出ししておきたい情報をサーバー起動時に解決することにより、より柔軟にサーバー初期化をおこなうことができる。
- インスタンスに任意のタグをつける機能を利用して、インスタンス起動時にタグ情報やメタデータを読み込み、それに応じた設定を動的におこなう、というアプローチがある。
- StampパターンやBootstrapパターンを使った汎用的なベースイメージに対して、固有の設定をおこなうことができる。
Backnetパターン
- 外部公開目的のWebサーバに複数の仮想ネットワークインタフェース（ENI）を設置し、公開用のネットワークインタフェースと管理用のネットワークインタフェース（「バックネット」と呼ばれる）とに分け、それぞれを別のサブネット（パブリックサブネットとプライベートサブネット）に紐つける。
- 高いセキュリティレベルが要求される場合、信頼できるアクセスとそうでないアクセスが同じネットワークインタフェースを利用することは避けるべき課題となることが多い。
- パブリックサブネットでは、
0.0.0.0/0（全トラフィック）を外向けのインターネットゲートウェイにルーティングする - プライベートサブネットでは、
0.0.0.0/0（全トラフィック）を社内イントラなどにつながるVPNゲートウェイにルーティングする。SSHアクセスや管理/ログ用途にもこちらを用いる。 - 異なるファイアウォールルールを各ENIに適用することが可能のため、それぞれに合った適切なルールを設定することも可能。
- 複数の仮想ネットワークインタフェースを利用しても、インタフェースが論理的に分かれるだけで物理線が分かれるわけではないので、帯域が増えるわけでもない点については注意する。
Multi Load Balancerパターン
- Webアプリケーションをマルチデバイス対応させる場合に、設定が異なる複数の仮想ロードバランサを割り当てるパターン。
- アクセスデバイスごとのSSIやセッション振り分けなどの設定をインスタンスにおこなわせると、サーバー台数が増加した際の設定変更が煩雑になる。
- 同一のインスタンスで、マルチデバイス対応が可能になる。
- ロードバランサから切り離す必要がある場合には、全てのロードバランサから切り離す必要がある点に注意。
Floating Gatewayパターン
- IPアドレスやルーティングを同一にした設定を持った仮想ネットワークを複数作成しておき、そのゲートウェイを付け替えることで、開発環境やテスト環境、ステージング環境といったネットワーク環境を簡単に切り替えるパターン。
- 同一ネットワークレンジのVPCに対しては、VPNでは同時に接続はできない。
本書に出てくる各パターンを端的な日本語でまとめてみる
上記のものも含め、各パターンについて自分の言葉でもまとめてみておく。
基本パターン
- クラウドのスナップショットは基本差分で取れるので便利
- スナップショットからマシンイメージを作ると同じ構成のインスタンスを無限に作れる
- サーバースペックも動的に変更できる
- プログラマブルにインスタンスの数を増減できるので負荷分散するとよい
- ディスクも動的に増減させられるのでキャパシティプランニングをそんなに厳密にしなくてよい
可用性向上パターン
- サーバーやデータセンターの冗長性の確保もクラウドならしやすい
- IPアドレスの動的変更もクラウドならAPIからできる
- ルートテーブルを使ったフェイルオーバーもAPIから可能
動的コンテンツの処理パターン
- ファイルの共有はNFSで
- ユーザー情報の共有はキャッシュサーバを噛ませて
- 静的コンテンツの配信はCDNで
静的コンテンツの処理パターン
- オブジェクトストレージを使った配信やホスティングもできるように
- 期限付きURLを生成できる機能も
- グローバルに展開しているクラウドの場合、ユーザーのロケーションに合ったエッジサーバーが使われ、またエッジサーバーからオリジンサーバーへのキャッシュ更新もロケーション考慮させることができる
データアップロードのパターン
- オブジェクトストレージにデータを配置する場合でも、直接アップロードさせるかどうかは一考の価値がある。
- ユーザーの利便性をとるか？サーバー管理の難しさを取るか？
- オブジェクトストレージにデータを配置するだけでなく、その検索性は十分であるかどうか？についても検討する。
リレーショナルデータベースのパターン
- 耐障害性を向上させるためのレプリケーション。
- データベースは読み込みオペレーションがメインとなることが多く、それに対してスケールアップなどに加えて、リードレプリカの利用を考える。
- また、そもそもデータベースへのアクセスを回避させるためにキャッシュを用いるパターンも。
- 書き込み性能を向上させるためにはスケールアウトさせシャーディングさせる。
非同期処理／バッチ処理のパターン
- キューイングサービスは、処理の非同期化・サービスの疎結合化の味方。
- 各システムをキューイングサービスが橋渡しすることで、システム全体が柔軟になる
運用保守のパターン
- 現場の状況に応じて、完全なマシンイメージを維持しつづける方法から、起動時に差分を更新する方法まで、幅がある。
- APIによりサーバーインスタンスを動的に操作できるようになったことで、クラウドインフラやその後の設定をコード化することもできるようになった。
- 監視レイヤーは「ハイパーバイザー側」「サーバー内部側」と大きく2つに分かれる。
- 動的にサーバー台数が増減することによって増えた悩みもある。スケールしたサーバーからのログの集約がそのひとつ。ただアプローチもちゃんとある。
- 「必要なときだけ起動」といった、従来までは作業コスト・金銭的コスト面から現実的ではなかったオペレーションも、クラウド化によって可能になった。
ネットワークのパターン
- ネットワークインターフェイスやルートテーブル、ファイアウォールルールに対する、APIによる付替・設定変更がクラウドの強みを活かすにあたってのキモ。
- 従来までの環境であればコストが高かったロードバランサも手軽に扱えるようになった恩恵も大きい。
- VPCにより、同じネットワーク構成を簡単に複数つくることができるようになった・ピアリングできるようになったという利点もある
- 自律的、という点もキーワードか？動的にサーバーが増減するからこそ、以下に人手を排除し自動化するか・環境自らが適切な設定を自動的に持てるか、といった観点も鍵か。
全体的な感想
おおむね以下のような感想。
新しいクラウドサービスが登場することで、デザインパターンも新しいものが発明される（できる）ところもまた面白いポイントだよなー
— a-know | Daisuke Inoue (@a_know) 2019年1月3日
この本自体は良書だと思うのだけど、少し古い（僕が手に取ったのが遅いだけではある......）ということもあってか、新しめのクラウドサービスを活用するようなパターンは掲載されてはいなかった。KinesisとかLambdaとかを使う前提であれば、多分まだ倍くらい、 "クラウドデザインパターン" と呼べるものとして定められるんじゃないかなと思った。例えばその代表格として、ゆううきさんの以下のブログでまとめられているようなアーキテクチャは "クラウドデザインパターン" の新しいもののひとつになり得るものなんじゃないかなーと思うのだ。
そういうところも含めて、クラウドデザインパターン、おもしろいなと思いました。
