この記事は Chatwork Advent Calendar 2020 2日目の記事です。
前日はプロダクトマネージャー宮下の「SaaS エンジニアのキャリアパスとしてのプロダクトマネージャー」でした。
全国のエンジニアの皆さん、こんにちは。
コアテクノロジー開発部 Scalaエンジニア の 辻（ @crossroad0201 ） です。
2020年5月にChatworkに入社して気がつけばはや半年... Creator's Note には初投稿となります！！
この記事では、私も参加しているChatworkのアーキテクチャ刷新プロジェクトで現在検討している内容についてご紹介したいと思います。
なお、ここでご紹介する内容はまだ検討、設計、プロトタイピング、テスト、検証...を繰り返している段階ですので、まだ実際のプロダクトで採用されているわけではないことをご了承ください。
なぜ今、アーキテクチャを刷新するのか
プロダクトとしてのChatworkは2010年にPHPを使って開発され、2011にサービス提供を開始。
その後システムの一部をScala化（Falconプロジェクト）したり、コンテナ化してAWS EKS上に配備したりと改善を繰り返しながら現在に至っています。
これは私も入社してから知ったのですが、Chatworkに限らずビジネスチャットツールはすでに多くの企業で当たり前のように使われていると思いきや、実はまだまだで認知度は30%程度、実際に継続的に利用しているのは13%程度しかいないそうです。
今後、テレワークなどの場所にとらわれない働き方が広がっていく中で、ビジネスチャットツールの需要と重要性はますます高まっていくと思います。
Chatworkも利用ユーザー様が右肩上がりに増えているのですが、その一方で長年運用されてきたシステムゆえの課題も出てきました。
- いわゆる技術的負債によって、新しい機能の追加や既存機能の改善をするのに時間がかかってしまい、ビジネス上の機会を失ってしまう。
- 仕様が複雑でわからない。誰に聞けばわかるのかもわからない。
- 開発体制を強化しても、アーキテクチャ上の制約で開発をスケールしづらい。
こう言った課題をソフトウェアアーキテクチャ面から解決するために、さまざまな技術や方法論を検討・評価しています。
検討している主要技術
現在有力視して評価している主な技術には以下のようなものがあります。
よく聞くキーワードが並んでいますが、リアクティブシステムやイベントソーシングは聞いたことはあるけど実際どうなの？と言う方も少なくないのではないでしょうか。
- モジュラモノリスとマイクロサービスアーキテクチャ
- リアクティブシステム
- イベントソーシング+CQRS
- ドメイン駆動設計(DDD)
ここでは簡単に紹介するだけですが、詳細については弊社テックリードのかとじゅん（ @j5ik2o のブログ「リアクティブは難しいが役に立つ」が詳しいので、そちらもご参照ください。
モジュラモノリスとマイクロサービスアーキテクチャ
既知のとおり、ビジネス上の意思決定をすばやくプロダクトに反映させていくためには、システムが巨大な一枚岩では困難です。
考えるスコープが大きくなりますし、調整しなければならない範囲も広くなり、どうしても時間がかかかるようになってしまいます。
弊社の新しいアーキテクチャでも、この問題への解決方法としてマイクロサービスアーキテクチャを採用したいと考えています。
ただし、最初から過度なマイクロサービスへの分割はせずにまずはデプロイ単位は少なくしつつ論理的に疎結合・単方向依存とした「モジュラモノリス」な構成からはじめ、段階的にマイクロサービス化していく構想です。
リアクティブシステム
前述のように、社会においてビジネスチャットツールが果たす役割はますます大きくなっていき、より「必要なときにいつでも使えること」が求められていくと思います。
これに対するアプローチとして、Reactive Manifesto で定義されているリアクティブシステムとして設計しています。
すなわち、
- 即応性 (Responsive)・・・ユーザーに常に安定した応答時間で応答を返すことで、「いつでも使える」と言う信頼感を持ってもらう。
- 耐障害性 (Resilient)・・・何らかの障害が発生しても影響を局所化し、即応性を保つ。
- 弾力性 (Elastic)・・・システムの負荷に応じてスケールし、即応性を保つ。
- メッセージ駆動 (Message Driven)・・・非同期なメッセージのやり取りによってコンポーネント同士を疎結合にし、障害の影響を隔離したり、個々にスケーリングできるようにする。
のような性質を持つようにします。
具体的には Lightbend社 が提供するリアクティブシステムの開発を支援するフレームワーク／ツールキット、 Akka を積極的に利用しています。
リアクティブシステムについては、Lightbend社が提供しているオンライントレーニング Lightbend Academy - Reactive Atchitectureトレーニングパス がとても勉強になるのでオススメです。
ドメイン駆動設計
Chatworkはシンプルなビジネスチャットツールですが、その仕様は思いのほか複雑です。
これを紐解いて自己完結したユーザー価値の境界を見極め、それらを独立マイクロサービスとして開発していくために ドメイン駆動設計（Domain Driven Design=DDD）を使います。
また、DDDのユビキタス言語によってビジネスとプログラムコードの距離を近づけ、事業上の意思決定をすばやくプロダクトに反映したいと言う狙いもあります。
イベントソーシング+CQRS
これからの需要増に対応できるスケーラビリティ、ユーザーに常に正しい動作を保証する一貫性、障害が起こってもその影響を局所化してユーザーの利便性を損なわない可用性、これらすべてを高い次元で両立させることは非常に難しいです。
そこで CQRS（=Command Query Responsibility Segregation）パターンを導入して、適材適所で使い分けるようにします。
Commandは強い一貫性を保証しますが、可用性を少し犠牲にします。
Queryは可用性を重視しますが、一貫性は結果整合性になります。
Chatworkで考えると、メッセージの投稿などはCommand、チャットルーム内のタイムラインの表示はQueryとして分離することで、万が一障害が起こったときにメッセージ投稿はできなくてもすでに投稿済みのメッセージを見ることはできます。
イベントソーシングについては必須ではないとする見方もあり、私自身もこれまでにCQRSパターンを使ったシステムでもイベントソーシングは採用したことがなかったのですが、今回は組み合わせて使っています。
その理由は相性の良さと言うこともありますが、CQRSにおけるクエリ用のデータ（リードモデルと呼んでいます）は永続的なものではなく、必要に応じて再構成したりプロダクトの事業成長によって後発的に追加されることを想定した場合に、イベントさえ記録されていれば後からいかなるリードモデルでも新たに構築することができる強みがあると思います。
これはデータを上書き更新して最新状態しか残らないステートソーシングではできない芸当です。
これからの取り組み
現時点では、上記でご紹介した技術を使ってプロトタイピングを行い、概ね要件を満たすことが確認できたところまで来ていますが、実際のプロダクトで採用するためにはサービス提供を開始した後の運用面をさらに詰めていく必要があります。
また、何よりもこのアーキテクチャ上でプロダクトを開発していく社内のエンジニアから関心と賛同を得られるようにしたいと思っています。
まとめ
以上、ざっと概観ですが現在検討を進めている新しいアーキテクチャについてご紹介しました。
私個人的にもこのアーキテクチャで実際にプロダクト開発して運用していくのを楽しみにしています。
最後になりますが、ChatworkではScalaエンジニアを積極採用中です！ 今回ご紹介したアーキテクチャに関心のある方！ぜひ一緒にやっていきましょう〜
