AWS インフラ構成図 プロの仕事から必要なインフラ構成を逆算する① 学習編

インフラ

みなさん、お久しぶりです。Junです!

今回は、AWSに関するインフラの学習用に「インフラ構成図 公開 事例」をGoogleで検索してみました。

上記のように、各企業が公開しているインフラ構成図が出てきます。

今回は、この画像の中の一番右下の画像をちょっと見てみます。

au WALLETという携帯で支払いができるシステムのインフラ構成図だそうです。

ちょっと複雑ですね(笑)

しかし、プロは、上記の画像を見ただけで、当然何をして、どういう意図でこの構成図ができているか、汲み取り、説明ができるはずです。この画像の資料自体は2016年に作成されたものだそうです。

上記画像を簡潔に説明できるのが、プロの仕事ではないか!と考えるのですが、現状、パッと見ただけではまだうまく説明できません。(正直に・・)

そのあたりを目指して、今回、検索・調査を行なっていきます。

しかし、現状、小さくステップアップしていく方が、効率的だと思うので、別のインフラ構成図をチョイスしてみました。

今回、こちらの「株式会社サイバー・コミュニケーションズ様の社内での基幹システム」の画像を説明しようと思います。矢印が色分けされていて、どんな機能かがわかりやすいので、説明を組み立てる側としてはとっつきやすいです。

では、上記のインフラ構成図をノートに丸写しし、一旦、インプットします。

その後、こちらの記事を読み、構成した方の意図を確認します。

~AWSクラウドの特性により、社内基幹システムの設計から構築まで3ヶ月の期間で完了することができました。~

AWS 導入事例:株式会社サイバー・コミュニケーションズ

ノートや、記事を眺めながら、わからない箇所、気になった部分を、また別のノートにまとめました。

そのあたりで、今の知識でわかる箇所、わからない箇所、グレーに分かれるので、わからない場所、グレーの部分を検索し、大体機能が想像できるレベルまで情報を補いました。推測の部分をなるべく確定情報に置き換えていき、今回の説明を構築しました。100%当たっている説明かは不明ですし、担当者の方に話して確認もとっていませんが、大まかな意図の70%程度当たっていれば、このインフラ構成図に関しては「理解」自体はできているかなと思います。

そのインフラ構成図に関して、各種アイコンの機能、経路、全体の中でアイコンのグループがどんな役割を持っているかを、最小の視点から中間の視点、最大に俯瞰した視点の3つを組み合わせて、説明していこうと思います。

中間の視点・ VPCの『冗長性』

上記の図を理解するために、まず記事を確認したのですが、その中の文言に、

システムの完全停止を防止するための冗長化策

株式会社サイバー・コミュニケーションズ テクノロジー・ディビジョン エクゼクティブ・テクニカル・エキスパート 宮一 良彦 様

とありました。この部分がどこかを探すと、下記画像がその一部にあたりそうです。

冗長性、冗長化とは何かというと、いわゆる「コピー」です。冗長とは、不必要なものがくっついて、無駄に長い、という意味を持ちますが、ここでの冗長化、冗長性はプラスの意味に転じてコピーして片方がダメになっても、もう片方が大丈夫なので、アプリケーション起動上はそちらの経路を使えば問題がない、ということです(解釈)。

また、上記の図では、(手書きで失礼します・・早くて頭に入るので、ノート化した画像を使うことにします。)冗長化した箇所が、VPCに対してと、AvailablityZoneに対して、二箇所の冗長性が見て取れます。

VPCとは、Virtual Private Cloudの略で、仮想的固有クラウド、つまりクラウド空間における自分専用のサーバー環境のことです。そのサーバー環境では、セキュリティが担保されていて、ある経路を通らないと外部からアクセスできません。つまり、外部から「決められた端末」からしかアクセスできないようなセキュリティが構築できます。

上記の図では2つの”VPC”が用意されていますが、「評価」と「本番」とあります。「本番」の方の文字が、間違えて「開発」を消して書かれていますが、「本番」です。「本番」は文字通り、ユーザーがアクセスする本番環境になります。一方、「評価」は単純に、作ったアプリケーション(App)がVPC内のサーバーにおいて動くかどうか、検証する環境になります。評価環境で試して、クラウド上で問題なく動作すれば、本番環境へ同じものをデプロイする、という流れになりますが、その環境もまた、「冗長性」を含んでいるように思います(無駄ではないので、正確には違いますが・・)。

最小の視点・マルチAZ構成における『冗長性』

もう一度、先ほどの画像をチェックしておきましょう。

下記画像の「マルチAZ構成」を一度チェックしておきます。

 「マルチAZ構成」とは、Availablity Zone(AZ)を2つ置き、その中に全く同じファイル構成をおくことで、サーバーがダウンした際に、もう片方のサーバーにアクセスを誘導する、という構成です。先ほどの冗長性を持った構成になります。また、一番右側のAZの中に、3つの四角が入っているのですが、これと同じものが真ん中のAZの中にあります。右と真ん中は「冗長化(コピー)」された構成に見えます。さらに、真ん中と左のAZは、「EC2File」という四角が左側には欠けていますが、やや冗長化されているように見えます。

 このことから、「冗長化すべき」ポイントは、「ユーザーのアクセスするアプリーケーション側」にのみ、コピーを作成したとわかります。逆に、EC2Fileには、冗長化を持たせていないことが伝わります。ここから私見ですが、EC2Fileは、アクセス数がAppにアクセスするユーザーの半分以下になっていることが予想されます。アプリケーションから、ファイルの読み出し(開く)、書き込み(保存)をする、といった操作をするユーザーが少ないので、冗長化すべきなのはAppのみにし、コスト面を抑えている工夫があるのではないか。と自分は考えています。

上記「冗長性」を持たせることで、片方がクラッシュしても、もう片方を稼働させるスタイルが、安全に運用を行う上での工夫になるのだと考えます。

以上で、最小・中間の視点により、VPCがなぜ2つあるか、マルチAZ構成によりアプリケーションの稼働を担保しつつ、EC2Fileサーバーを一つにするコスト面での工夫がなされていることを説明しました。次は、最大の視点に戻ったときに、「監視」における項目を説明したいと思います。

最大の視点・監視を行う『Cloud Watch』

インフラ構成図に戻ります。

冗長化によって、複数の「冗長性」を持たせることにより、安定稼働に保険をかけました。

次は、「監視」に関して「Cloud Watch」「監視サービス基盤」の説明になります。

Cloud Watchとは、監視している対象に条件を設定し、特定のログを通知させることができる機能(使ったことはないので、だいたいこんなもんかなぐらいでお願いします・・_:(´ཀ`」 ∠):)だと思います。

例えば、ユーザーがアクセス過多により、AutoScalingによる最大値を超える直前の95%ほどアクセスで埋まってしまう状況になった場合に、その旨を通知するログを吐き出させ、それをメールで通知したり、ユーザーが、アプリケーションへのアクセスを本来の目的以外のプログラムを送信し、クラッシュを試みるなど、不穏な動きに対してメールで通知するなど、監視対象に対して特定の条件を設定し、条件を満たしたときに通知する機能を持っているのが「Cloud Watch」です。

「監視サービス基盤」とは、24時間365日、人がPCの前に張り付いて、異常があった場合に担当者の方に通知する「インフラ監視・運用」のサービスだと思われます。

そのため、インフラ担当の方が、CloudWatchにより異常を検知したことを、オペレーターの方が伝えてくださるので、夜間対応でも「監視」のできる構成ではないかと思います。

以上で、「冗長性」、「監視」の二つに分けて上記インフラ構成図を説明できました。

上記を参考に、実際に環境を整え、AWS上で構築すれば、この環境については習得できると思います。実操作でできて初めて「習得」になると考えるので、これは「予習」になります。

以上、選んだインフラ構成図に関して、説明を構築する、の記事(第1弾)でした!

コメント

タイトルとURLをコピーしました