インターネットで発生した問題がAWSに影響した例
以上、ベストプラクティスのご紹介をさせていただいたので、次はそのようなベストプラクティスを実践いただいていてもなお影響を受けてしまうような、実際に起こった過去の事例を紹介させていただきたいと思います。
お客さま側で避けるのが難しい問題の事例となりますので「そんなこともあるんだ」くらいで読んでいただくとよいかと思います。
本事例は、2015年6月30日5:30pm（米国太平洋時間）頃に発生しました。こちらの事象はタイトルの通り、実際にはAWSのネットワークの外部、つまりAWSに到達するまでの経路上で発生した問題でした。
事象の内容としては、米国内で一部（といっても比較的多く）のISPを経由して、AWSで運用されているNetflix、Slack、Pinterest、HipChatなどを含む、複数のお客さまのサービスに接続できないといったものでした。
何が発生したのでしょう？ 次のブログ記事「Route Leak Causes Amazon and AWS Outage」に非常に詳しく解説されていました。
ごく簡単に説明すると、こんな感じになります。
インターネットのバックボーンでは各ISPが自分が中継できるネットワークをお互いに広告しあってます。自分が知らないネットワークに関しては他から広告された経路の中からベストだと思うものを選び、そちらへパケットを送信（中継を依頼）します。本事象が発生した際、Axcelx（AS33083）というネットワークが「うちのネットワーク経由でAWSに到達できるよ」と誤って広告してしまいました。上述のブログ記事中のFigure 4がそれ示してます。図中の16509と7224がAWSを示しています。
「AWSに到達できる」と言うのは簡単ですが、しかし大量のトラフィックを中継する必要があります（数百Gbpsから数Tbpsは定常的にあるでしょう）。残念ながら、Axcelx自身もその上位のISPであるHibernia（AS5580）もその区間には十分な帯域がなく、図中の赤線部分がひどく輻輳することとなりました。事象発生時のインターネットのルーティングの変化を、RIPE NCCが提供しているBGPlayを使ってアニメーションにするとこんな感じになります（三角の再生ボタンをクリックしてみてください）。AS13030からAS16509への経路が突然AS5580、AS33083経由になるのが分かっていただけるかと思います。
「でも、ISPって冗長化されてるんじゃないの？ なんで正常な経路を通るようにならなかったの？」
もっともな疑問です。しかしここが難しいのですが、インターネット（というかIPルーティング）では基本的には一つの宛先には一つの経路しか選べないのです。選んだ経路が回線が切れたとかで「使えなくなった」場合は別の経路を選択できるのですが、今回のように輻輳していても「使えてる」場合は別の経路へ迂回しないため、輻輳した経路を通り続けてしまいます。
さらに本事象（「経路ハイジャック」と呼ばれたりします）の難しいところは、AWSは事象の発生に関与していないし、簡単には対応できないところにあります。事象の発生は他のISPが誤った経路広告をしたことであり、その誤った経路広告を信じた他のISPはAWSに到達できなくなります。
その際、影響を被った側としてAWSが技術的にできることは限られています。当該ISPにコンタクトして修正を依頼するといった運用的な対応は可能ですし、おこなっていたと思われます。また、より細かい経路を広告する、という対応もよくおこなわれます。しかしいずれも効果が出るまである程度時間がかかりますし、効果が限定的な場合もあります。
このような問題は日常的に発生しており、インターネットの標準を策定している団体であるIETFでも長い間大きな課題として取り組まれています。
さらに、残念ながらこのような問題の際は、AWSに到達する前に輻輳が発生することが多く、AWS内でのアベイラビリティーゾーンによる冗長化は多くの場合でその効果が限定的となります。一方、複数リージョンやCloudFrontなどを活用し、できるだけエンドユーザーに近い場所からデータを送信することで中継ISPを減らすといった対策を実施することができます。
また、IPルーティングにおけるこの「一つの宛先には一つの経路しか選べない」という性質は色んなところで同様の問題を引き起こします。
たとえば先述の「AWSのリージョンとアベイラビリティーゾーン」では、Transit Centerが複数で冗長されており一方の問題が他方へ影響しないと説明しました。しかし、ここでの問題と同じように、たとえばTransit Center内で「使えないわけじゃないけど使い物にならない」ような問題が発生すると、やはり冗長化されても結局切り替わりが発生せず冗長構成が役に立たないといったことも起こり得ます。これには、トラフィックが集中するコアネットワークでは問題が検知されたからといってすぐに冗長経路へ迂回してしまうとかえって状況が悪化してしまったりと、切り替えのための閾値の設定も一筋縄ではいかない、といった背景もあります。
すっきりした解決策が無いのがツライところですが、インターネットのルーティングセキュリティの向上を進めていくのが肝要だと思います。また、AWSのリージョンを外部からサービスを監視することで、問題が発生した際に素早く対処できるような体制を準備しておくことも効果的でしょう。
モトネタ
なお、ご存知の方は気づかれたかと思いますが、本稿は以下のプレゼンテーションの内容をもとにしています。
- AWS re:Invent 2014 | (SPOT301) AWS Innovation at Scale
- AWS re:Invent 2015 | (NET403) Another Day, Another Billion Packets
いずれも、毎年米国で開催されているAWSの最大規模のグローバルコミュニティである、AWS re:Inventでのプレゼンテーションです（今年のAWS re:Inventは2016年11月28日〜12月2日です）。
"AWS Innovation at Scale" はAWSのJames Hamilton氏（VP and Distinguished Engineer（当時））による発表であり、AWSの（ネットワーク）アーキテクチャを、全世界に広がるバックボーンから始め、サーバのNICまでDive Deepしていく、中々他では見られない内容がてんこ盛りでした。
また、"Another Day, Another Billion Packets" は同じくAWSのEric Brandwine氏（Senior Principal Security Engineer（当時）、VPCを作ったチームのメンバー）によるプレゼンテーションです。こちらはAWSの初期のEC2のネットワーキング（EC2-Classic）の説明から始まり、どういった制約があったか、そしてその制約をどう解決してきたかについての解説になります。特に、AWSにおけるネットワークのスケーラビリティの課題を、昔ながらのルーターやスイッチによるネットワーク技術ではなく、Mapping Serviceの導入によって解決してきたという話は、前職でネットワークの設計・構築をやっていた自分には非常に興味深かったです。
いずれのプレゼンテーションも本稿で触れなかった内容を多く含んでおり、非常に興味深い内容となっておりますので是非ご覧ください。特に "Another Day, Another Billion Packets" の「VPCエンドポイント」に関する箇所はオススメです。ちなみに筆者は2014年当時はまだ前職で働いており、プレゼンテーションを見ながら、その巨大なシステムの裏側へと思いを馳せていたものでした。
終わりに
AWSは2006年にサービスを開始し、今年2016年で10年になります。にも関わらず、ネットワークという非常に基礎的かつシンプルなレイヤでもまだまだイノベーションは発生しています（"Another Day, Another Billion Packets"で触れられているVPCエンドポイントや、VPCフローログもその一つです）。
AWSでは毎年のように新しいサービスがリリースされ続けていますが、それもよく設計されたインフラストラクチャーがあってのことだと個人的には思っています。Amazon.comのCTO Werner Vogels氏によるブログ記事「AWS10年に学ぶ10のレッスン」でも「ネットワークの重要性」はその一つとして挙げられています。そしてそれは本稿で解説してきた通り単なる謎テクノロジーではなく、AWSの10年の歴史の中で多くの異なるワークロードに対応する過程でより洗練されてきたものであり、そしてこれからも進化していく技術であると思っています。
これからもAWSのイノベーションにご期待ください。
なお、アマゾン ウェブ サービス ジャパン株式会社ではクラウドサポートエンジニアを絶賛募集中です。 誰よりもAWSの仕組みを深く知り、最先端の技術に触れられる刺激的な仕事です（本稿よりももっと突っ込んだところを知ることができますよ！）。
興味を持ってくださった方はこちらからオープンハウス参加の登録をお願いいたします。
