「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏(前編)
日本でも選挙活動にインターネットを利用するという議論が始まっていますが、世界でもっとも大規模にインターネットを利用して選挙活動が行われたのが、昨年の米大統領選挙です。
その選挙戦を勝ち抜いたオバマ大統領のチーム「Obama for America」が、どのような選挙キャンペーンシステムを構築したのか。3月15日に都内で行われたAmazonクラウドのイベント「JAWS DAYS 2013」で、語られました。
そこでは、過去の選挙データやソーシャルメディアなどを元に有権者の動向を徹底的に分析し、テレビCMの打ち方からボランティアの働き方まであらゆるものを最適化する大規模なシステムをいかに構築したのか。そして、大規模システムでクラウドを活用するとはどういうことか、ということを学ぶ絶好のサンプルになっています。
国内でこのシステムの舞台裏がこれほど詳しく紹介されることは初めてのはずです。講演の内容を詳しく紹介しましょう。
Behind the Scenes of Presidential Campaign
Amazon Web Services、Solution Architect ManagerのMiles Ward氏。

「Obama for America」とはボランティアの団体です。たくさんのボランティアをコーディネートしたり、有権者の方々に選挙登録や投票をしてくれるようにお願いしたりしていました。そして選挙を通じてアメリカを変えていくのです。
私たちはそこでどんなシステムを構築したのか。AWS(Amazon Web Services)のテクノロジーをどのように使い、非常に安価にもかかわらずスケーラブルで高性能なシステムをどう構築したのか、そこで学んだことなどを今日は紹介しようと思います。

私はAWSの社員で、ソリューションアーキテクトをしています。
ただし米国の法律では、企業が特定の候補を支援してはいけないことになっています。AWSも候補者に対して公平公正でなければなりません。ですから私は休暇をとってボランティアとして、無給でObama for Americaの仕事をしていましたし、ほかのメンバーたちもそれぞれ自分でできることを持ち寄ってシステムを構築していました。
ボランティアの開発スタッフで200ものアプリケーションを開発
さて、私たちは何を構築しようとしたのか。200種類ものアプリケーションを開発し、4万人ものボランティアをコーディネイトするシステムです。しかしながらそれは、選挙が終わればすぐに撤去しなければなりません。

しかも分析のために何百テラバイトものデータも扱います。ソーシャルメディアからの情報、有権者のデータベース、地理別分析データ、選挙の状況分析、過去の選挙結果など、とにかくアメリカ国民のデータのほとんどすべてが必要です。
しかもパブリックなWebサイト「www.barackobama.com」もあります。これは大統領のWebサイトですから、国民がみんな見ることもあるわけです。そうした大規模なトラフィックにも自動的にスケールするようになっていなければなりません。
こうしたシステムを作るのは、エンジニアとしてとてもやりがいのあるものでした。
しかし選挙の7カ月前にはエンジニアは4人しかいませんでした。みんなボランティアで、週末や夜、あるいは仕事に行く前の早朝に集まっていました。デベロッパーの平均年齢は24歳。私は年寄りな方でした。
しかも納期が決まっています。投票日は11月7日。みなさん、これまで仕事をしてきて納期を絶対に守ってきた、という人はいますか?(笑) 納期を守るのは簡単ではありませんが、でもこの納期は法的に決められた絶対に変更できないものです。

システムを構築したのはこんな人たちです。みんなあごひげをはやした、ちょっとおかしな人たちですね(笑)。彼(前段右から2人目)がCTOでアーキテクトの責任者でした。その後ろが私で、その右の彼(後段一番右)はいまNASAで働いています。彼(前段中央)はTwitterで働いて、彼(後段左から2人目)はAWSで働いています。

仕事場所は24時間ずっと、まるで大学の寮のようにコーヒーやピザやドーナッツやビールがその辺に転がっていて、うるさくて汚い場所でした。

しかしながら、本当に専門的で高度なエンジニアが集まっていました。これは投票日の夜の写真。彼はグーグルCEOのエリック・シュミット氏です。

選挙当日に絶対に落ちてはいけないシステムを作る
ここで数百のすべてのアプリケーションを説明する時間はありませんが、ほとんどがHTML5とレスポンシブWebデザインを採用し、モバイルやタブレット、デスクトップなどに1つのコードで対応しました。どれも選挙当日に100%の可用性を実現しました。個別のシステムコンポーネントを実行しているEC2インスタンスが落ちたとしても、システム全体としては稼働し続けるようになっているのです。

そうした成功があり、そしてオバマ氏は大統領に当選しました。
レスポンシブWebデザインでHTML5で、1つのコードベースでモバイルに、タブレットに、デスクトップにとさまざまに対応するもので、どれも100%のアップタイムを選挙の日に、この日のために作りました。どの個別のシステムのコンポーネントを実行しているEC2インスタンスが落ちたとしても、システム全体として動作するようになっており、それが成功し、そしてオバマ氏は当選しました。私たちは勝ったのです。
システムの状態を示すチャートはたくさんありますが、どれも皆同じ、こんな感じです。選挙前はそれほど稼働しておらず、選挙当日に突出した稼働となるのです。この日のためにシステムを作るのです。

リードデベロッパーのScott VanDenPlasが、システムについてツイートしています。2000のEC2インスタンスノードが起動し、毎秒1万のリクエストがあり、180TBのデータウェアハウスに対して85億回ものリクエストという非常に巨大なシステムです。

私たちは当初、あまりお金がありませんでした。選挙の寄付金というのは直前になって集まるものなのです。しかも前回の選挙ではシステムで使ったハードウェアを廃棄するのにも大変な手間がかかったのです。
そこで作ったのがこれです。ここに描いてあります。このAWSのクラウドを使ったアーキテクチャが成功しました。(この図はここから見ることができます)

システムのあるパーツに注目してみましょう。これはロードバランサー、水平分散、マルチAvailability Zone、セキュリティグループ、オートスケーリングループ、Amazon RDSデータベースなどで構成されています。どれも以前からある機能で、新しいものは何もありません。これをアプリケーションごとに同じように構成したのです。もちろんアプリケーションに応じた設定が異なったり、可用性が非常に重要なものはAZを3つにするといった違いはありますが。

また非常に大規模なDynamoDBも利用し、毎秒あたりギガバイトもの処理をしていました。
そして重要なことは疎結合にしたということです。バックエンドとフロントエンドを分離したうえでSQSで接続し、障害が起きてもほかに影響を与えないようにしました。

200もの異なるアプリケーションでも、その多くは寄付金を処理したいんですね。すると課金処理をしなければなりません。PayPalとやりとりをしたり、クレジットカードの処理をしたりと、さまざまな機能が必要で、しかもそれぞれの実装はさまざまです。
もしアプリケーションが4つか5つならば、それぞれに課金処理を組み込むのも容易でしょう。でもそれが200もあればどうでしょうか。もしあとで課金部分に変更があったときに、いちいち200のアプリ全部を書き換えなければなりません。
そうする代わりに、1つの課金APIを用意してWSDLを公開し、周囲のアプリケーションから利用可能にするのです(WSDLとは、WebサービスとしてAPIを公開するための設定ファイルのようなもの)。そうすると各アプリケーションでいちいち課金処理をプログラミングする手間が省けます。AWSではこの課金用のセキュアなAPIも用意されているのです。
≫後編に続きます。後編では大規模アプリケーションの例などを紹介します。
あわせて読みたい
「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏(後編)
≪前の記事
OpenStackとはコードでありコミュニティである。ベンダーロックインには「ノー」を。OpenStack Day Tokyo 2013基調講演