AWS のデータセンターに侵入する（妄想で）

AWS の中身はどうなっているの？

　AWS インスタンスを立ち上げたとき、なんとなく Virtual Machine 上で 仮想OSが立ち上がっているんだろうなーというのは分かるけど、実際の物理層はどうなっているんでしょうか。データセンターはどこにあって、何台くらいのサーバが動いていて、どのラックのどの VM 上にインスタンスができるんでしょう。
　そんなこと知らなくてもサーバ立てることはできるし、障害にも強いらしいし、知らなくてもいいことなんだけど。でも、わたし気になります！

ナイショです

　AWS はデータセンターの場所は非公開、どこにあるか教えてくれません。物理層の内部仕様も非公開で re:invent でチョイ出しする程度です。
　ここはささやかな抵抗として、物理構成を想像で補完し、妄想によるデータセンターへの侵入を試みます。

こんな構成で構築しました

　手始めにサーバ 1台、ボリューム 1台の構成でサーバを構築してみました。データセンターに侵入しこのときの物理的な情報を見ていくとともに、対障害性の向上を検討します。

• インスタンスタイプ：t2.micro (1vCPU/1GiB)
• VPC：１つ
• サブネット：1つ
• AZ：ap-northeast-1a

AWS データセンターに来ました

　データセンターは地震や洪水といった自然災害が少なく、安定した土地に立てられるものなので、どのあたりに建っていそうかはある程度予想がつきます。洪水・液状化などあらゆるハザードマップを見ながら捜索範囲は東京だけでなく関東全域に及び、埼玉県某市にあるという妄想に至りました。
　こちらのビルです、写真をご覧ください。

　これが ap-northeast-1a の実物です、10年以上経過しているにしてはきれいな外見ですね。表には看板すら出ておらず、ぱっと見データセンターだとわかりません。警備員やビルから出てきた人間にインタビューしても、社名すら教えてくれません、さすがにしっかりしています。¹

侵入に成功しました

　入館認証、入室認証、監視カメラ、静脈認証、等々の超厳重なセキュリティを忍術により突破しサーバルームへ侵入。物理構成を念力で透視することにより、前述のインスタンスとボリュームの可視化に成功しました。
　前置きが長かったですが、次からが本編になります。

サーバ構成

解説

インスタンス

　AWS ではハイパーバイザに Xen をカスタマイズしたものを使用しているそうです。大量の Xen Server があり、その1台の上にゲスト OS としてインスタンスがいました（オレンジ）。
　物理ホストの電源喪失、ハイパーバイザの障害、H/W 障害はインスタンスに波及することになります、それを監視してくれるのが Cloud Watch であり、EC2 ステータスでよく見る Check Status 2/2 ですね。
　EC2 インスタンスは起動するたびに別の物理ホスト上で立ち上がります（薄いオレンジ）。EC2 メンテナンス時に再起動依頼のメールが届きますが、物理ホストからどいてもらうためのオペレーションです。起動したままホストを移動する Live Migration はできないようです。Auto Recovery もこれと同じ仕組みで、別筐体に移すことでリカバリが行われます。
　ハイエンドなブレードサーバに何百台もサーバがあるわけではなく、ローエンドなブレードサーバに数十台のインスタンスが起動できる設計がされており、安価で大量にというモデルです、t2.micro を選びましたが、高 GPU だったり、HPC なインスタンスを選べば別の筐体に起動されることでしょう。

　障害時には再起動でリカバリできることはわかりましたが、現状の構成ではデータセンター全体が壊れると復旧できませんので、EC2 インスタンスは Multi-AZ 構成にしたほうがよさそうです。

ネットワーク（SDN Layer）

　だいぶ想像ですが、各ハイパーバイザは巨大な SDN（Software Defined Network）で接続されています。今回の VPC / Subnet（黄色）が見つけられます 。 ²

ボリューム（SAN Layer）

　EBS ボリュームも巨大な SAN のなかにいました（赤色）。仮想ディスクであるため、物理ディスクをまるっとマウントしているわけではないですね。EBS ボリュームは自動的に同一 AZ にレプリケートされているので（ピンク）耐久性も高いし故障率も低くなっています。ネットワーク的には直接サーバに SCSI マウントされているわけではなく、iSCSI（SCSI over IP） や FCoE（FiverChanner over Ethernet）が使われており IP で接続されています。⁴

構成の改善点まとめ

• Multi-AZ 構成にしよう
• EBS Snapshot を定期的に取ろう

　なんか聞いたことのある結論ですが、物理層から見ても一般的なプラクティスと同じ結論に至るということでしょう。

おわりに

　いかがでしたか？
　利用者の目には見えない物理レイヤーを妄想してみるのは、なかなか楽しいですね。
　結果的には大きめなデータセンターらしい普通な構成ですが、物理レイヤーを意識することでボトルネックへの気付きにもつながりました。
　また、インフラについて詳しくないところ調べながらで記事を書いたので、個人的に勉強になりました。

注意事項

• 想像なので、実際の構成とは大いに異なると思います
• 想像なので、NDA に抵触する情報は含まれていません
• 知識不足により、図や用語には間違いが含まれると思われます

参考書籍

クラウドを支える技術 ―データセンターサイズのマシン設計法入門 (WEB+DB PRESS plus) 単行本（ソフトカバー） – 2014/9/26

　記事を書いていたらデータセンターの設計にすこし興味が出てきたため読みました。電源・空調の設計からコンテナ型データセンター、スーパーコンピュータとデータセンターの違いなど、普段意識しないところの説明がされており、興味深く読めました。

参考サイト

製品の詳細 - Amazon EC2 | AWS
製品の詳細 - Amazon Elastic Block Store（EBS） | AWS
製品の詳細 - Amazon VPC | AWS
How did they build that — EC2 Enhanced Networking | Cloudier Than Thou
Windows Insider用語解説：Software-Defined Network（SDN）とは何か？ - ＠IT
AWS箇条書きナレッジ - Qiita
Awsの質問に何でも答えます
AWS re:Invent 2016現地レポート - 通信すら飲み込むAmazon、ルーター用半導体も自社開発と公表：ITpro

1. 関東に限らず大阪や北海道にあるやもしれません。1b や 1c でなく 1a にたどり着けたのはご都合主義である為です。 ↩

2. 1台構成なので繋がりがいまいち表現できていません。ネットワークは二重化されていますが、記載省略しています。
   　VPC やサブネットを構築したとしても SDN 上で論理的なネットワークが構成されるだけで、物理的なネットワーク構成とは関係ありません。ネットワーク機器のメンテナンスは利用者まで波及せず、自動で SDN 上の論理構成が変更された上でネットワーク機器のメンテナンスが行われるものと思われます。³ ↩

3. SDN コントローラーの記載も省略しています。実際にはもっとかっこいいメッシュネットを構成しているでしょう。 ↩

4. データとチェックディジットがストライピングにより分散した上でレプリケートしていると思うので、データはもっと分散しているはずですが、省略。
   　
   　耐久性が高いことはわかりましたが、現状の構成ではやはりデータセンターが逝くと復旧できませんので、定期的に EBS Snapshot をとることにしましょう。EBS Snapshot は バックグラウンドでは S3 を使用しており、3つ以上の AZ にレプリケートされます。 ↩