Twitterの一連のシステムは、バックエンドのユーザプロファイル / tweet / タイムラインから、HTTPリクエストを処理するフロントAPIのエンドポイントに至るまで、Finagle上で構築されてます。同社のエンジニアブログでその概要が紹介されています。

障害耐性があり特定のプロトコルに依存しないRPCフレームワーク for JVM

Netty (NIOクライアントサーバフレームワーク) 上に構築。SOA (サービス指向アーキテクチャ)では上流サービスの待ち受けをしている時間が長いので、非同期処理ライブラリが効果的。

Twitterのプロトコル関連実装は、HTTP / Thrift / Memcached / MySQL / Redis / SPDY / PostgreSQL / WebSockets / IRC / AWSに渡る。

SOAにおいて、多くのサービスを経由するリクエストのパフォーマンスイシューのデバッグには、Finagleのトラッキングフレームワークが有効。

Finagleのクライアント/サーバ相関図

1. Finagleクライアントの下には、Finagleトランスポートのレイヤがあり、Nettyをユーザから抽象化する役目を果たしている。
2. NettyのChannelPipelineにある、ChannelHandlerの実装が実際のワークをする。
3. Finagleサーバが接続ごとに生成され、読込み/書込みをするトランスポートを提供する。
4. ChannelHandlersが、プロトコルの暗号化/解除ロジック、接続レベルのstat、SSLなどの実装をする。

抽象化: type Service[Req, Rep] = Req => Future[Rep] のコードにおいて、Futureは、ネットワークRPC / タイムアウト / ディスクIOなどの非同期オペレーションの結果を保持する。中身が空であればまだ結果はこない。成功であれば、オペレーションの結果が入り、exceptionを保持していたら失敗というシンプルな仕組み。

障害耐性: Finagleのクライアントがローカルで各ホストの負荷を把握し、新しいリクエストの向け先を調整する。リクエストが失敗すると、Finagleは接続を切り、そのホストはロードバランサーから外される。バックグランドではFinagleが再接続をトライしつづける。再接続が確立されれば、新しいホストがロードバランサーに追加され、安全に個別のホストのシャットダウンができる。ヘルスチェックで万全でないと判断された接続も切る仕組みになっている。

データフロー、並列処理はFinagleに任せるので、スレッドプールや競合状態は気にしなくてよくなり、コードがクリアで安全に保てる。

#twitter #オープンソース #java #scala