NewsInsight

年賀状サービス「ウェブポ」開発のリプレックスに聞く

Amazon EC2で大規模サービス、クラウド時代のシステム開発とは

2009/11/30

　「クラウドがなければ、さあこれから年賀状シーズンが始まるという今になっても、要件定義すら終わってなかったかもしれません」。こう笑顔で語るのはベンチャー企業「リプレックス」（Ripplex）の代表取締役、直野典彦氏だ。

　同社は2009年10月29日、Webサイト上から手軽に紙の年賀状を送れるサービス、「ウェブポ」を、日本郵便と連携してスタートした。前例のないサービスであるため、フタを開けてみないと最終的な利用者数や年賀状の数はまったく予想できないというが、数百万、あるいはそれをはるかに上回る利用もあり得るという大規模なサービスだ。年賀状の印字イメージをPDFとして生成する重たい処理もある。

　このシステムの大部分を、リプレックスではAmazonのクラウドサービス（AWS：Amazon Web Services）上に構築したという。チームメンバーは9人、開発に要した期間はわずか数カ月。

　構築したシステムは、Amazon EC2／S3／EBSを中心に、仮想ロードバランサ・サービスの「Amazon ELB」、東京にもエッジノードがあるというCDNサービスの「Amazon CloudFront」、JVMレベルのクラスタリングを実現するOSSの「Terracotta」などを組み合わせた先進的なものだ。

　＠IT編集部では11月27日、リプレックス代表の直野氏、CTOの太田智久氏、スペシャリストの高尾知則氏に、サービスの狙いや、クラウド利用のメリットを聞いた。

年賀状は日本最大のソーシャル・グラフ

　「去年（2008年）の10月から社内で話が始まり、初めて郵便事業会社さんにご案内したのが2009年2月ごろです」（直野氏）。実際にシステム構築を始めたのは5月ごろで、実質半年程度でサービス公開というスピード展開だ。

　ウェブポが構想段階だった2008年の暮れには「mixi年賀状」が話題となり、類似サービスと見られることが多いが、直野氏は両者の狙いは異なるという。mixi年賀状が、あくまでもmixi利用者向けのサービスであるのに対して、リプレックスが目指すのは、こうしたSNSなどが持つソーシャル・グラフ（人と人とのつながりの情報）を相互利用する世界という。

　リプレックスは、もともとネット上にバラバラに存在するアイデンティティを集約し、サービスをまたいで人と人をつなげるサービス「Ripplex」の開発・提供を行っていた（参考記事：ソーシャルアドレス帳「Ripplex」がSkype、Twitterと連携開始）。今回の年賀状サービスも、Ripplexと同じ線上にある。

　ウェブポではTwitterやGmailといったサービスと連携し、相手の住所を知らなくても年賀状が送れるという仕組みを実現している。具体的には、OAuthを使ってTwitterなどから連絡先を引っ張ってくる、という機能を利用している。こうして得たオンラインの連絡先から年賀状を送りたい相手を選択すると、その相手にウェブポから通知メールが届く。この通知メールを見て、年賀状の受け手は住所を入力するか、もしくは受け取り拒否の理由を選択肢方式で選ぶ。

　TwitterやGmailとの連携機能だけを聞くと、ネットとオフラインをつなぐサービスの一種という印象を受けるが、直野氏はオンライン、オフラインの区別は本質的ではないと見ているという。

　「ソーシャル・グラフといえば、SNSのようなオンラインのものを想像されるかもしれませんが、携帯電話の電話帳のようなものや、年賀状をやり取りする人の間にもソーシャル・グラフは存在しています。ネットに限定しなければ、1億人が30億枚もやり取りする年賀状というのは、日本最大のソーシャル・グラフなのです」。

　年賀状のやり取りなどからソーシャル・グラフをすくいだすことができれば、そこから先には冠婚葬祭の案内状や礼状、季節ごとのギフトの送付など、より大きな市場が広がる可能性がある。直野氏は、そう見ているという。

CDN活用で遅延の問題を解消

　Twitterやメールサービスとの連携が注目されたが、むしろウェブポで想定している主要な利用層は、これまで店舗やネットで年賀状印刷を注文したり、年賀状ソフトやプリンタを使って年賀状作成を行っていた一般のユーザーだ。

　利用者は、ウェブポのサイト上で送りたい相手の住所を入力するか、各種年賀状ソフトから、もしくはCVS形式で宛先となる住所をアップロードする。続いて写真のアップロードやデザインの選択をした後に、フォントや文面を加工する。後は提携先の富士フイルムが実際の年賀状にプリントして、実際に送り先に郵送してくれる。手元にプリンタや年賀状ソフトが不要で、印字も専門業者なので美しい。手書きのひと言を書き添えたい利用者は、ダイレクトに宛先へ郵送するのではなく、いったん自分宛に年賀状を送るというオプションも選択できる。

　デスクトップの年賀状ソフトなみのリッチな環境は、Adobe Flash／Flexで実現した。これは4種類のフォントを備えた年賀状デザインのアプリケーションを実現するためという理由に加えて、米国にあるAmazonのサーバ群を利用する制約から来るデザイン・チョイスでもあったという。クラウドサービスではインスタンス数は負荷に合わせて増やせるが、「なるべく、クライアント側に処理をオフロードしたかった」（CTOの太田智久氏）のだという。クライアント側で作成した年賀状データは、クラウド側にはテキスト情報として送られ、これをサーバ上で再びPDFへとレンダリングする。PDF生成にはオープンソースのiTextを使い、実際のPDFデータの保存にはKVSのAmazon SimpleDBを使った。

　Flash／Flex採用には、アニメーション作成などでFlashの専門家と分業するためという理由もあったという。エンジニア中心のリプレックスでは、UIデザインを外注に任せる必要があったため、コーディングはFlexで、デザインはFlashで分業して行い、それをswfファイルにまとめるという開発スタイルが有効だった。

　ウェブポの年賀状作成アプリケーションは、起動時に計20MBのフォントを含むデータをクライアント側にダウンロードしてくる。このとき、アプリケーションの設定ファイルや解析用ビーコンといったファイルをのぞき、ほとんどのファイルをクライアントはAmazon CloudFrontのキャッシュから読むことになる。太田氏は「CDNによるキャッシュなしでは、起動に1分ほどかかって使い物になりません」と話す。海外のクラウドを利用しつつ、多くのファイルを東京のデータセンターから読み出すよう設計すれば、遅延を防げるというわけだ。

　CloudFrontは各都市にエッジサーバを持った安価なCDNサービスだが、いざ使ってみると使いづらい面もあったという。ファイルの設置後、24時間は上書きができず、キャッシュのクリアや更新ができないという問題だ。キャッシュの有効期限を長めに取り、ファイル名やURLにリビジョン番号を入れることで、ファイル内容を更新した場合に最新のものを使うようにする、というテクニックもあるが、これはウェブポのトップページ（index.html）では使えない。このため「トップページだけは国内のさくらインターネットのサーバを使っています」（太田氏）という。「われわれの目的はAmazon EC2を使うことでもクラウドを使うことでもありませんから、適材適所で使い分けています」（同）。運用監視についても、AWSが提供するAmazon CloudWatchサービスではなく、OSSの「munin」を使っているという。

自前で用意するより、提供サービスを使う

　ウェブポのシステム概略図は、以下の通り。Amazon EC2やブロックデバイスとしてEC2にマウントできるストレージサービスのAmazon EBSは、米国東海岸の2個所に存在していて冗長構成にしてあるという。EC2上で動かすOSとしては、扱いに慣れているという理由から、Debian GNU/Linux＋Apache tomcatという構成を選択した。

　写真などはAmazon S3に保存しているが、ウェブポで扱うほとんどのオブジェクトはTerracotta上に存在している。TerracottaはJVMレベルでクラスタを実現するオープンソースのミドルウェアで、複数あるサーバのメモリを仮想的に1つの大きなメモリ空間として扱うことができる。

　11月末現在は、Amazon EC2で利用できるインスタンスのうちメモリが15GBのExtra Largeインスタンスを2つ起動しており、合計30GB分がTerracottaで扱えるようになっている。クラスタリングによるメリットは、メモリ容量が増えるということ以上に「異なるアプリケーションサーバ間で透過的にメモリ共有ができる」（高尾氏）という点にあるという。ロック周りもサポートしているため、アプリケーション設計がステートフルでありながら、サーバを容易にスケールアウトできることがポイントだという。

　Amazon EBSに用意したPostgreSQLは、このTerracottaのバックアップとして機能している。データセンター2つにまたがったPostgreSQLはリアルタイムのレプリケーションも行っている。

　Terracottaで扱うメモリ空間は2つのデータセンターにまたがっているが、Amazon ELBはKeepAliveを保持している間は同じサーバにつなげてくれるため、同一ユーザーはほとんど同じサーバにアクセスすることになる。このため、Amazon ELBによる分散とTerracottaの相性は良く、障害時に備えた冗長性は確保しつつ、通常時のベストエフォートを確保できるという。

　アマゾンは2009年10月27日にMySQLのホスティングサービス「Amazon RDS（Relational Database Service）」を開始している。太田氏は「PostgreSQLで行ったわれわれの作業はなんだったんだと思いましたね。この発表があと3カ月早ければ、PostgreSQLではなくAmazon RDSを使ったと思います」と本音を明かす。セキュリティパッチや冗長構成、バックアップなど運用面の面倒は任せて、サービスがあるならそれを使うというスタンスだ。

　ロードバランサとして「Amazon ELB」を使ったのも同様の理由だ。当初はロードバランサとして、HAProxyやnginxといったオープンソース実装をAmazon EC2上で動かすことを考え、実際評価もしていたという。ただ、工数の問題から、アマゾンが提供するものを利用したほうが手っ取り早いと判断。ELBであればトラフィックが増えて負荷が上がったときに、インスタンスを自動で増やすなどスケーラビリティでの安心感もあるという。

　Amazon ELBを使う上では、独特の“クセ”も感じたという。クラウド上ではIPアドレスが動的に変化するため、ロードバランサでもIPアドレスベースの設定ができず、必ずサーバ名をCNAMEで登録するのだという。

　いずれにしても、この辺りの実装をアマゾンは詳細に明かしていないため“ブラックボックス感”があるのは否めないという。ただ、「アマゾンのサービスはSLAがあるものが多く、全体にビジネスで使えるという印象を受けた」（太田氏）という。AWS採用を決める前には、Google App Engineの利用も検討したが、自社開発の暗号システム「SecuTect」の実装が難しいこと、SLAがないことなどが理由で、App EngineではなくAWSを選択したという。AWSのほうが抽象度が低く、これまでのシステム構築・運用のノウハウがすべて生かせるというのも選択の理由だという。

クラウド利用の本質は価格ではない

　直野氏は、クラウド利用の価値は、容量単価が安いかどうかだけで計れないという。

　例えばウェブポでは、AWSのサービスを利用したり、オープンソースのミドルウェアを組み合わせたりと、システム構築時にかなりの試行錯誤を短期間で行っている。数カ月のタイミングの違いで、PostgreSQLではなく、Amazon RDSを使っていた可能性もあるし、Amazon ELBではなく、HAProxyを使う可能性もあった。

　「日々新しいフレームワークが登場し、毎月のようにアマゾンからもサービスが登場します。こうしたものを試して、試行錯誤する過程がないと、すべて枯れた技術を使うことになり、最新技術を享受できません。同時に大規模な商用サービスですから、万が一にもお客様にご迷惑をかけることはできません。この厳しい制約の中、次々と現れる最新技術のメリットを享受するためには、試行錯誤が簡単にできるアマゾンのようなクラウドサービスが必須なんです」（直野氏）

　Terracottaの性能評価のために、サーバを2台調達するといったことは、従来のハウジングや、部内サーバの流用では手軽にできない。「結局、リソースの余っているWikiサーバなんかに入れて、訳が分からなくなるのが関の山（笑）、アマゾンなら最新のセキュリティパッチが当たったクリーンなOSインスタンスが瞬時に立ち上げられます」（太田氏）

　金融系のシステムエンジニアからリプレックスに転職した高尾氏は、こう指摘する。「一般的な案件ではテスト環境の準備だけでも大変で、そのために工数が伸びることも少なくありません。すぐに試せる環境を用意できるのは、クラウドの強みです」。

　ウェブポ開発は9人のチームで行っているが、これが一般的なSIerなら40〜50人、開発期間も2倍程度かかるのではないかという。Terracottaのような、ある意味では“未知のソフトウェア”を自力で評価の上、導入を決定できないとすれば、「大手ベンダさんに依頼してお金で解決」（高尾氏）という方法を取らざるを得ない。

運用やメンテナンスに固定費が要らない

　直野氏は経営的観点から、チームを小さく保てることのメリットも強調する。

　「世間ではクラウドは安い安いと言いますが、容量単価などで見れば安くも高くもありません。高くないのに柔軟性がある、というのがすごいのです」。

　「クラウドではシステム運用の固定費も劇的に下げられます。固定費とは、つまり人件費です。人材採用には採用までのリードタイムもあれば、期待した人材が来ないというリスクもある。そうした経営判断をせずに済むのは大きなメリットです」。

　「開発環境やテスト環境の構築など開発現場のオペレーションで表に見えないコストというものがあります。クラウドは、こうしたコストを削減してくれる効果が大きい。このメリットを考えると、『クラウドは安くも高くもないけど、同じ値段なら得だよね』ということになるのです。ただし、従来環境に比べると、使いこなすためには、ユーザー側の高い技術力、柔軟な発想、それと迅速（じんそく）な意志決定が必要なのも事実です。クリック1つですべての人のニーズを満たす夢のインフラというわけでは、もちろんありません」。

　12月の半ばを過ぎ、年賀状シーズンが本格化したときのスケーラビリティについても、当然クラウドのメリットが生きる。負荷に応じてEC2のインスタンスを増やせばいいからだ。ウェブポでは、ピーク時には10〜20台分ほどのインスタンスが稼働することになるのではないかと見ているという。

　AWSではELBとCloudWatchを組み合わせることで、自動的にインスタンス数を増減させるオートスケーリング機能を提供している。ただ、「まだ挙動が怪しい」（太田氏）ために採用を見送ったという。こうした嗅覚が、クラウドを生かしたスピーディーなシステム構築に欠かせないのかもしれない。

　負荷状況を監視して自前でオートスケーリングする仕組みを作ることもできるが、今回のケースでは「手動でインスタンスを起動・終了しても、十分」（太田氏）と判断したという。過負荷状態になるリスクや、オートスケーリングの実装工数を考えれば、常に多めに多めにインスタンスを起動しておくという対策のほうが費用対効果が高い、という判断だ。

クラウド時代のスピード感を証明

　リプレックスのウェブポは、「われわれには引きずるものがなかった」（直野氏）から実現できた面がある。それにしても、これだけ大規模なサービスを、たった9人という少人数で、最新技術を組み合わせてあっという間に実現するというスピード感には目を見はる。ウェブポのシステム構築は、少数精鋭のエンジニアチームがあれば、これまでとは桁違いのスピードとコストでクラウド上にシステム構築が可能ということを証明する事例と言えそうだ。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）