「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏（後編）

2013年3月18日

日本でも選挙活動にインターネットを利用するという議論が始まっていますが、世界でもっとも大規模にインターネットを利用して選挙活動が行われたのが、昨年の米大統領選挙です。

その選挙戦を勝ち抜いたオバマ大統領のチーム「Obama for America」が、どのような選挙キャンペーンシステムを構築したのか。3月15日に都内で行われたAmazonクラウドのイベント「JAWS DAYS 2013」で、語られました。

（本記事は「「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏（前編）」の続きです）

アプリケーション開発を優先した開発環境に

Amazon Web Services、Solution Architect ManagerのMiles Ward氏。

私たちは非常に幅広いプログラミング言語、フレームワーク、データベースなどを利用しました。

チームはボランティアのデベロッパーで構成されています。私たちがもしも会社であり、社内でRubyを開発言語にしていたとすれば、「私はPHPが使えます」という人が来ても「ウチではいらないよ」といって採用しなければいいのです。

しかしボランティアであれば「PHP？いいですよ」と言います。RubyでもPythonでも、Node.jsでもOKなのです。データベースだって何でも使います。なにしろ人手が足りず、開発日数も残り少ないのです。毎日アプリケーションを開発し続けなければなりません。

これでは運用チーム、DevOpsエンジニアの仕事は難しくなるかもしれません。それでもアプリケーションを開発するデベロッパーの使いやすい言語、フレームワーク、データベースなどを使いました。そうやって大量のアプリケーションを作ったのです。

ソーシャルメディアのデータを分析し活用

ここではCanvasというモバイルアプリケーションを紹介しましょう。これは国民に投票してもらうためのものです。国民は選挙人登録をしていないと投票できないので、4万人のボランティアが全国を一軒一軒回って、「私はオバマの支持者ですが、もう登録はしましたか？」と訪ねて回るわけです。でも、忙しいボランティアの方々に、例えばすでに登録済みの人や、同じ家を何度も訪問して時間を無駄にしてほしくない。

ところが、政府の選挙人データベースは一週間に一度しか更新されません。非常に遅いわけです。そこでCanvasがずっと稼働していて、「登録したよ」といったTwitterのツイートやFacebookへの書き込みを集めて中央のデータベースに入れます。そしてそれを分析するのです。

分析結果などにより、ボランティアのモバイルアプリケーションの画面には地図とともに、この家に行ってくださいとか、ここは行かなくていいです、といった情報が表示され、ボランティアはこれを見ればスマートに仕事ができるようになるのです。

別の例を紹介しましょう。テレビ広告は非常にお金がかかります。その費用対効果を高めるため、特定の地域ごとに投票者の嗜好を分析するのです。TwitterやFacebookの情報を元に、どんなテレビ番組や映画、書籍を好むのか。分析を元に、ある地域の若者や女性が特定の番組を好む、といったことが分かれば、そこにコマーシャルを打つのです。

これによって2億ドルも広告費用を圧縮し、よりよい広告を打つことが出来ました。これはわずか3人のエンジニアによって実現されました。

この実現にはAmazon EMR（Elastic MapReduce）が欠かせませんでした。Twitterからは毎秒650MBものツイートデータがFirehose（Twitterの全データをリアルタイムに取り込める特別なAPI）で送り込まれてくるのです。

こうしたアプリケーションが200種類も開発されました。

多言語開発、クラウド、多様なデータベース、疎結合

私たちはこれらを開発し、最適化し、決して障害で止まったりしないようにしなければなりません。そのためのテクノロジーの選択を次のように行いました。

まず多言語で開発をしようと。これには運用チームの作業が増えたり、開発者はプラクティスを共有できないというリスクがあるかもしれません。

また、クラウドを利用することにしました。これはインフラの制御の自由度が下がったり、性能が出ないのではないかという心配がありました。

アプリケーションを中心にして、多様なデータベースを採用することにしました。しかし大規模なデータベースでそんな大変なことができるのかという懸念や、なにか障害が発生したときの復旧が困難ではないかといった心配もあります。

そしてSOAによるシステム統合。SOAは複雑なシステムであり、若い開発者にそんなことができるのかという懸念がありました。

しかしマイナスの面だけではありません。こうした選択のメリットとして最初のリビジョンがすごく速く開発できました。若いやる気のある開発者がクラウドをすばやく理解し、スケーラビリティやアベイラビリティを実現できました。

処理の途中でデータベースを入れ替える

例えば、テレビで副大統領候補のディベートがあったときです。誰もがこの番組を見て候補者を見極めようとします。そしてそのあいだ、寄付も多く集まります。このとき、1分あたり40万ドルもの寄付が集まろうとしていたのですが、私たちのシステムにもう余力はありませんでした。しかしこれを失うわけには生きません。

このトランザクションの最中にデータベースを入れ替える、などと考えますか？とても恐ろしいことですよね？

しかし、私たちはそのデータベースの手前にフォールトトレラントを実現するためのキューを入れておきました。そして、いったん本番データベースをオフラインにし、データベースを別のデータベースへコピーし、そのIOPSを1000から1万へと10倍に設定してオンラインに戻したのです（データベースサービスのAmazon RDSには、ストレージのIOPS性能をパラメータで設定できる機能がある）。

オフラインのあいだリクエストがキューに積み上がっていきましたが、データベースをオンにしてからは、キューの中身がどんどん処理されていきました。私たちはうまくやったのです！

キューの仕組みはシンプルですから、ActiveMQやZeroMQなどさまざまなソフトウェアがあります。しかしそれが200ものシステムで使うとなるとどうでしょう？簡単であってもいちいちインストールして起動し、設定し使えるようにするには手間がかかりますし、トラブルが発生したときの解決も面倒です。

ですから私たちはロードバランサー、キャッシュ、データベースなど、どのシステムでも繰り返し使うものはAWSのサービスを使って構築し、いちいちインストールする手間を節約しているのです。その方がコストも安い。

私たちには時間がないのです。設定や導入などに費やして無駄にしたくありません。すでにあるサービスを利用し、その時間を新しいものを作る方にかけるべきなのです。

東海岸から西海岸へ9時間でシステムを複製

クラウドを活用した別の例を紹介しましょう。

投票日の11日か12日前に、ハリケーンサンディがデータセンターの近くまで来ようとしていました。東海岸のデータセンターは強固であり嵐にも耐えられる高い耐障害性を備えたタフな施設です。

けれど私たちは決して投票日に失敗してくれるな、というプレッシャーを受け、複数の地域にシステムのコピーを持った方がいいと考えました。

3カ月かけて東海岸のデータセンターで開発したシステム、520のインスタンス、15の大きなデータベースなどを、わずか9時間で西海岸のデータセンターに構築しました。アメリカ大陸をまたがった3000キロも離れた場所に、27テラバイトものデータを送ったのです。

もちろんAWSを使い、ツールはPuppetを、クラスタをデプロイするのにはAsgardを、WANに最適化したリンクをCloudOptで作りました。

障害時に自信を持って修復できるように準備をする

最後に、Obama for Americaで学んだことを紹介しましょう。

選挙当日に失敗しないよう、事前に「ゲームデイ」というのをやるべきです。

これはチームを2つに分けて、片方は好きなだけシステムを壊していい。SQSのキューを消したり、EBSをデタッチしたり、オートスケールのグループを書き換えたりして、クラッシュさせようとする。もう一方はそれを可能な限りできるだけ早く直さなければなりません。

これは本当にシステムが壊れても、すぐに直せるようにするためです。

ここにはもう一人、実はアシスタントがいます。うまい修復のやり方のメモをとる人です。それをスクリプトに書いて修復できるなら、将来システムが壊れたときにそれを再利用すればいいのです。何かが壊れたときに「修復するにはここをこうすればいいかな」と考えるのではなく、スクリプトですぐに直せる。

若いエンジニアたちは、こういうことを一度やると自信を持てるようになり、システムの修復を恐れなくなります。

これは選挙当日の1カ月前にやったのですが、すごくうまく行きました。本番直前にEBSの障害がありましたが、自信を持ってすぐに直せました。

疎結合も重要

そしてまた、疎結合も大変重要です。単にミドルティアとデータベースを分けるだけではなく、UIの中も疎結合で、この部分はRubyで、この部分はPHPで作ったりします。例えば全部Javaで作っていたとすれば、全部同じ障害で倒れる可能性があるのです。

しかもレスポンシブWebデザインで作っていれば、パーツごとにオフにできます。

先ほどのCanvasを例にすれば、地図を表示するシステムが壊れても、リストを表示する部分は生き残っている、という具合。このように構造的にシステムが守られるすることはとても重要です。

あるアプリケーションは静的にS3のページを生成していて、それは「友人を見つけて、投票に誘おう。そして自分も投票しよう」というシステム。選挙当日に非常に重要なシステムです。たとえほかのシステムが全部壊れたとしても、少なくともこれだけは見えるようになっている。とても重要なので可用性をすごく高く作りました。

オバマ氏は、こういうシステムを望んだわけです。