Chatworkのメッセージング基盤システムのアーキテクチャ

アーキテクチャ図の解説

• WEB: PHPで実装されたサーバサイドのシステム(現行システム)。メッセージに関する機能はFalconシステムに委譲する。データベースにAmazon Auroraを利用する
  
• Falcon: メッセージング基盤システム
  
  • WRITE API: メッセージ投稿・編集・削除を受け付ける書き込み用APIサーバ。リクエストが成功するとKafkaにメッセージイベントを書き込む
    
  • READ API: メッセージの取得、レンジ取得などを受け付ける読み込みAPIサーバ
    
  • READ MODEL UPDATER: Kafkaに書き込まれたイベントを基にHBaseにリードモデルを構築するサーバ
    
  • SPARROW FORWARDER: リードモデル完了のイベントをPHP側に通知するサーバ
    

アーキテクチャ選択の背景や意図

「Chatwork」の開発は2010年に開始され、当初は内製フレームワークを用いた社内向けシステムとして運用されていました。2013年には公開サービスとしてリリースし、機能追加を続けましたが、その過程で技術負債も積み上がりました。総コード量は30万行を超え、中心的なクラスは1万行にも達しています。2014年からシステム刷新プロジェクトが始まりましたが、さまざまな課題があり2016年に中断の決断を下しました。その後、戦略を変更し、メッセージング機能に絞って新しいアーキテクチャへの移行を進めています。

プロジェクト再起動にあたっては、もっとも重要性が高いメッセージング機能を選定し、開発対象を絞り込むことでプロジェクトのリスクを最小限に抑える方針を取っています。新しいアーキテクチャに移行することで技術負債を解消し、将来的なシステムの拡張性を確保できると考えました。

新アーキテクチャの技術選定にあたっては、「高スループット・低レイテンシの実現」、「可能な限り障害に対して自己回復力を持つ」という要件を定義し、スケーラビリティと耐障害性に定評があるアプリケーションフレームワークとしてScala/Akkaを採用しています。加えて、ストレージにはHBaseとKafkaを採用し、アーキテクチャとしてはCQRS+Event Sourcingを採用しました。これによって書き込みと読み込みを分離することでスケーラビリティと耐障害性を確保しました。

現在のアーキテクチャの課題と今後の改善予定

このアーキテクチャにはいくつかの課題があります。
まず、メッセージ部分のデータベースをマイクロサービス化したことは成果ですが、主なビジネスロジックは依然としてPHP側の現行システムに残っています。現状のアーキテクチャとしては、変更頻度の高いビジネスロジックの分割統治には課題が残るためです。

また、HBaseの運用にも課題があります。HBaseは性能が高い反面、自前でクラスタを構築しているため運用コストが高く、さらにHBaseのためのLinuxディストリビューションがEOLを迎え利用できなくなるため、根本的な対策が必要になります。

今後はアプリケーション設計の改善を予定しております。現在はPHP側にあるビジネスロジックを、ビジネスドメインを意識しながら段階的に切り出している最中です。こちらも必要に応じて引き続きScala/Akkaの技術を活用する予定です。これにより、システム全体の整合性とメンテナンス性を向上させることが期待されます。また、HBaseの運用コストを下げるため、マネージドデータベースへの移行を検討しています。この移行によって運用負担の軽減とシステムの信頼性向上を見込んでいます。

【サービス公式サイト】
https://go.chatwork.com/ja/