HAROiDプラットフォームアーキテクチャ

はじめまして。
サーバエンジニアの鳥居と申します。
業務ではHAROiDプラットフォーム全般の設計/開発/運用などを担当しております。

先日より弊社の技術ブログが始まりました。
まず、エンジニア第一弾としてHAROiDプラットフォームのアーキテクチャについてお話をします。


サーバエンジニア目線のHAROiDサービスの特徴

前回、小野寺から概要を説明いたしましたが
弊社のサービスはTVの視聴をトリガーとしてアクセスされることが多いサービスです。
このため、番組での告知や企画トリガーが発生するとリアルタイムで一気にアクセスが増えます。

普段からこういったアクセスをいかに効率よく対処するかを考えてサービスの設計しています。


プラットフォーム構成

現在は大きく分けて以下のサービスが存在しています。

  • プラットフォームサービス
  • プロジェクトサービス
  • Bridgeサービス
  • リアルタイムログサービス

これらの特徴をかいつまんで説明します。


プラットフォームサービス

HAROiD全体を管理するためのサービスです。
個々のサービスと常にやりとりするため24時間365日稼働しています。
かつ、日常的に行われるTV連動企画のプラットフォームにもなるため
企画の規模に合わせて無停止でスケールする必要があります。


プロジェクトサービス

企画毎に動的に起動されるサービスです。
企画と言っても 本当に1度きりの企画、または 毎日/毎週など定期的に行われる企画 など
様々な種類があります。
そういった要件に応えるため、弊社製の管理画面からクラスタ起動/スケール/削除といったすべての操作を行うことが可能になっています。


Bridgeサービス

TVのデータ放送と通信する場合、BMLという規格に則って通信する必要があります。
TVとの通信は通常のWebと異なる部分も多く、直接サーバとのやり取りを行うことが困難です。
そのためBridgeサービスがその間の通信を仲介し、やりとりを容易にしてくれています。


リアルタイムログサービス

企画に参加したアクセスを集計し、どのようなユーザがどの程度アクセスしているかを
リアルタイムに可視化するためのサービスです。
kinesis+Lambdaを利用することにより、柔軟なスケールを実現しています。


要件を満たすために

サーバサイドの必須要件をまとめると以下のようになります。

  • 急激なアクセスが来ても問題のないインフラ
  • 無停止で、かつ頻繁にスケール可能
  • 企画ごとに出来るだけ干渉しないような構成を構築可能
  • いらなくなったら捨てられる
  • エンドユーザ/開発者は可変なプラットフォームのエンドポイントなどを意識せず利用出来る

まずオンラインスケールを実現するために、データストアの多くにはDynamoDBを利用しています。
さらに、DynamoDBStreamと組み合わせてデータ集計に利用しています。

イミュータブルなクラスタを管理するためにCloudFormationのJSONをバージョン管理し
任意のCFバージョンを任意の大きさで起動/更新することができます。

可変なエンドポイントや設定情報などは
Consul Agentで同期し自動的にすべてのサーバに伝搬させています。


プラットフォームの今後の展開について

まだ詳しくは言えない部分が多いのですが、
エンドユーザ/サードパーティ(企画用アプリケーション開発者)に対して
よりバリューのあるサービスや機能を提供していくロードマップがすでに引かれています。
それらをリリースしていくことによりHAROiDに触れていただくすべての方々に
よりよい価値を与えられると信じています。


次回以降の記事について

今回は概要レベルの話に留まりましたが
今後はもう少し個々の技術にフォーカスし、さらに面白いお話が出来ると思います。

また、サーバサイドだけではなくフロントエンドやその他技術に関するお話も続々掲載予定です。
今後も随時チェックしていただけると嬉しいです。
よろしくお願いいたします!