こんにちは。アメーバのネットワークアーキテクト、責任者のいづるです。
本当は子育てについて書きたいのですが、何でもお見通しのM.S氏から 「育児の話題は禁止だから」 と、前もって眉間に釘を刺されたので、渋々、子供と嫁とロックと哲学と青い空と広い海の次に好きな、ネットワークの話でも書いてみようと思います。
とは言え、ネットワーク機器のような、比較的単純なパターンマッチングの処理をひたすら高速にぶん回す世界では、CPUの処理速度が飛躍的に高まった現在でも、まだまだASICやFPGAなどのハードコーディングされたチップ処理が主流でございまして、、、つまるところ、ちょっと足を深く踏み入れた濃ゆいところはNDAベースのやりとりになったり、セキュリティ的に開示できなかったりと、本当に面白いところは大人として書けなかったりもします。
そんなわけで、何を書こうか悩んだ結果、アメーバというサービスを支える、ネットワーク基盤の変遷の歴史でも書いてみようと思います。が、普通に書くと面白くないので、ネットワークの話にも関わらず、活字だけでゴリ押ししてみます。絵図を描くのが面倒なだけなんじゃないかというのは気のせいです。
私が就業し始めた2006年夏頃(*)、アメーバは既にブログを初めとする複数のサービスが立ち上がっている状態でした。かなり規模の小さなサービスでも、ほぼ専用のFWやLBを上流に持ち、綺麗な縦割りの並列構成になっていたのを記憶しています。この構成の利点は、責任分界点がはっきりしている事で、実際、縦割りのサービス毎に違うベンダーさんが構築していたりしました。今では全て内製で行っていますので、その必要もありませんが。
一方、問題点はいくつかありましたが、最も顕著だったものは、縦割りのサービス間のリクエストが増えると、それらののトラフィックが、
サーバ_A → LB_A → FW_A → ルータ_B → FW → LB_B → サーバ_B
という無駄なルートを辿るという点で、この事が内部処理の著しい遅延を引き起こしました。
また、FWやLBは非常に高価な機器ですが、当時、ブログを除いては、そのリソースをフルに使うほどのトラフィックは流れていませんでした。ネットワーク機器のサイジングは、想定しうる突発的なトラフィック増にも耐えうるスペックを選定するのが基本ですから、つまり、並列に設置されたFWやLBの多くや、それらを繋ぐスイッチが、それぞれ余剰リソースを持った状態で運用していたわけです。
そこで、新規データセンターの構築に合わせ、CISCO社が提唱していたDataCenter2.0の設計思想を参考に、仮想集約モデルのネットワークを設計し構築しました。2007年中頃のことです。このモデルは、並列に並んでいたシステムを、VRFなどのネットワークの仮想化技術を用い、論理的にパーティショニングした上で、物理的に集約するモデルです。物理的な集約を支えるため、一台あたりの機器投資のインパクトは大きくなりますが、総額ではかなりのコスト削減が実現できました。また、各機器が持っていた余剰リソースも集約されるため、突発的な要求過多に対しても、今で言うところのエラスティックな対応が可能になるというものでした。
構築当初は順風満帆に見えましたが、トラフィックの増加とともに、やがていくつかの問題が発生しました。一番の問題は、ドラスティックな集約モデルをとったため、障害の影響度も集約されてしまったこと、つまり、全サービスに影響するような障害点が増えてしまった事です。また、アメーバがいわゆるブログサービスからコミュニティサイトとしての機能を強化するにつれ、サービス間連携がより強固なものになり、論理的なパーティショニングが意味をなさないばかりか、逆に、自由なサービス間連携を妨げる存在となり始めました。
そこで、VRFをroute-mapに置き換え、ポリシーベースルーティングをとり入れていく事で、少ないホップでのサービス間通信と、動的なリソース配分の両方を可能にしていきました。route-mapはVRF導入前にも使っていましたが、あくまでもイレギュラーなルーティング要件をサポートするためで、それ自体がベースとなるような使い方は、それまでしていませんでした。実はこの置き換え作業は今でも継続していたりするので、特に作業にあたるネットワークチームの皆には、申し訳ないと思うこともあるのですが、例えるなら、子供の頃の服が大人になると、物理的にはもちろんのこと、センス的にも着られなくなるようなモノなので、なんというかまあ許してください。
更にトラフィックが増えてくると、サーバへの負荷を分散するためのLBが、スペック的に捌き切れないトラフィックを受ける事態になることが度々あり、その都度、複数台に分散することになりましたが、こんな時もDNSラウンドロビンやMACStickeyなどの技術とともに、route-mapは活躍しています。本来であれば、リクエストが経由するLBが変わった場合、サーバからのレスポンスの戻り先として、デフォルトゲートウェイを新しいLBに向けてあげるか、iproute2などでゴニョゴニョする必要がありますが、これだと管理する項目が各サーバに分散されるため、運用負荷が増大するとともに、再分散設計にかかる時間も肥大化してしまいます。サーバとLBの間にルーティングポイントを置き、そこでのポリシーベースルーティングによって戻り先を決めてあげれば、フレキシブルなトラフィックコントロールが単一のコントロールプレーンから可能になります。唯一の難点は、サービスの肥大化に合わせて、route-mapの設定、特にACLの行数が増えてくると読みづらくなるということです。
そこで、この夏に本格稼働した新しいデータセンターでは、この読みづらさを解消する目的で、VRFとroute-mapを併用しています。具体的には、各LBに紐付けたVRFに対して、route-mapでポリシーベースルーティングをすることにより、可読性が増すとともに、各ポリシーやその元になるACLをClass的に、再帰的に扱うことが可能になるため、より直感的なオペレーションが可能になります。この使いやすさは、活字だけではどうやっても伝わらない気もしますが、コンフを貼るのも気が引けるので、戻りのルートを分散しなくてはいけなくなったら、是非使ってみて納得して下さい。普段から高級言語を使っている人にとっては、至極当たり前な最適化だとは思いますが、ネットワークのコンフィグレーションとしては結構イケてる設定だと、一人夜な夜なニヤニヤしています。
最後に、大規模サイトのサーバサイドネットワークの設計に対する哲学的な解は、
「集約するべきはあくまでもコントロールプレーンとリソースであり、常にロードは分散するべき」
というもので、集約するべきものと分散するべきものの取捨選択が非常に重要であり、かつ、その時々、規模感によって変位する位置付けに、如何に迅速に、如何に先回りして対応していくかという事が肝だと思います。これは視点を換えると、組織論など色々なものに適応できる、いわば黄金律的なライフハックTIPSでもあると思います。
、、、的な事を、そういえばうちの子が寝言で言っていました。 では、今回はこの辺で...ごきげんよう。
*M.S.注: 彼は個人事業主で弊社に就業し、その後正社員となっています。この時期は個人事業主でした。