少人数で運用できるサービス、技術投資の必要性…　Chatworkがユーザーを増やす過程で学んだこと

ファイル管理の課題と実施策

春日重俊氏（以下、春日氏）：その観点で、具体的にどんな対策を実施したのかでいうと、Chatworkは4つ大きな機能があり、これから説明する例でいうと、ファイルの管理です。

リリースした当初は、ファイルのアップロードに関して、EC2経由、実態をEC2に載せながらS3にアップロードするところがありましたが、ユーザー数が増えてくるとEC2側が詰まってしまう課題がありました。そこで、EC2側に過負荷がかかりすぎているところが、その性能監視ツールによって原因、ボトルネックがわかりました。

それに対する実施策みたいなところでいうと、Pre−Signed URLを発行して、EC2側でリクエストを受けますが、実際にユーザーからリクエストを発行されたものを、クライアントにPre−SignedのURLを発行するかたちにして。EC2を、実態を通さないかたちにして、負荷を下げるところで乗り越える対応を実施しています。

あと、例えばWebサーバーの監視運用みたいなところでいうと、もともとはEBSに全ログを載せていましたが、やはり用途に合わせて、例えばsyslogやtemporaryのログに関してはEphemeral Diskを使い、用途に応じてログの出力先を分けてWebのサービスのパフォーマンスを上げることを実施しています。

こういうことを乗り越えながらも、突然限界値がきたりします。Chatworkでいうと、MySQLで検索機能を提供していましたが、それが数千万件以上のレコードになってくると突然動かなくなってしまうような。そういうところがあり、全文検索エンジンを使うことによって乗り越えてます。

“製品内容による優位性の壁”の学び

このときの学びです。やはり少人数でも運用できるサービスを選択する重要性と、サービス特性に応じた事業に必要なツールを見極め、New Relicは当時は先進的というか、新しいと思いますが、必要だと感じたら積極的に投資していく。

あとはボトルネック。サービスを運営する上でのボトルネックは放置せず、1つずつ解決していくサイクルが重要かと思っています。

エキスパート藤原さんのインタビュー

この当時を支えくれた、エキスパートの藤原さんのインタビューがあるので、ぜひみなさん見てください。

藤原吉規氏（以下、藤原）：こんにちは。藤原です。大変ご無沙汰してます。アマゾンウェブサービスジャパン株式会社でソリューションアーキテクト、主に西日本のISV、SaaSのお客さまや、ゲームのお客さまに対して、技術支援を行うポジションに就いています。

CTO室という部署にいて、今でいうSRE的なポジションで仕事をしていました。ファイアーファイターという自称をもってます。

構成をできるだけシンプルにするのはやはりとても大切で、なおかつ一度作った仕組みを、そのまま何もメンテナンスせずに運用していけるわけではないじゃないですか。もちろんサービスのほうがどんどん成長していくので、維持するためだけでも多くの改善改良は加えていかないといけないので、やはり元の仕組みをどれだけシンプルに構成できるかが、非常に大きなポイントだと思っています。

今回Amazon Cloud Searchのインデックスをする際に、今振り返ってみると、SQSのキューを使ったり、ステートの管理でDynamoDBを使ったりしていますがる、このあたりもできるだけシンプルに工夫しながらアーキテクチャを作っていました。

このCloud Searchのバックエンドで見れる仕組みについて、当時参考にしていた本があります。たぶん今でもすごく役立つと思いますが、『Release It! 本番用ソフトウェア製品の設計とデプロイのために』という本があるのを知っていますか。

たぶん2008年ぐらいに出た本で、いわゆるソフトウェアのアーキテクチャとなどパフォーマンスと安定性を両立した仕組みをどうやって作ったらいいか、ソフトアーキテクチャをどうやって作ったらいいかという本になっています。いわゆる、当時の分散システムを構築するためのノウハウがたくさん詰まった本になっています。

これは今でも役に立つ本だと思うし、例えばサーキットブレーカーみたいな、今マイクロサービスのアーキテクチャだと当たり前の概念があると思いますが、そういったものも当時からちゃんと記載されていて、「考えて構築しないといけないですよ」というようなことがノウハウとして書かれています。今でも参考になると思うので、ぜひ見てもらえればと思います。

もうこれは完全に余談になりますが、当時のノウハウが今の仕事にも大変活きているので、感謝しています。

Growthフェーズの課題

春日：続いての壁ですが、少人数でのマーケットフィットがあることを証明した上で、この段階でChatworkも資金調達をしています。次にブチ当たる壁みたいなところでいうと、どんどんサービスを大きくしていったときに、Growthしてもプロダクトがちゃんと安定運用できるかをすごく気をつけなければいけないフェーズに差し掛かってきています。

こちらを​​Chatworkとしてはどう乗り切ってるかについて、これから紹介していきたいと考えています。

当時の展開面積の壁みたいなところのシステム構成です。先ほど紹介した少人数で乗り切りっていったところのLAMPの構成から、いわゆる検索のところに関していうと、全文検索エンジンであるCloud Searchを利用したり、キャッシュ層のところを入れたり。あとはリアルタイム性みたいなところを、トランザクション概念を少し緩めるようなキューを入れたりでやっていきますが、データをすべて格納しているところは、基本的にはRDSがマスターデータになっていました。RDSがマスターデータでやると、だんだんいろいろな壁が見えてきました。

サーバーとデータ容量の壁

まず1つ目の壁です。おかげさまでChatworkはサービスをリリースしてから、基本的には順調にユーザーが増えていきました。しかし、マスターのデータの保管箇所が1つだと、やはり保管するためのデータベースに対するWebサーバー、捌くためのウェブサーバーの数がどんどん増えていきます。

そうすると、同時に接続できる数にアッパーが見えてしまうので、どうにかして分散していかないといけないなところが、1つ課題になりつつありました。

2つ目はデータ容量の壁といったところ。Chatworkってチャットサービスなので、メッセージのデータをどんどん溜めないといけません。どんなにシンプルにデータを保管していっても、やはり容量はすごくどんどん膨れ上がってしまうので、容量を気にしないで保管できるようなサービスを構築しないといけないところが、至上命令になってきました。

そういったところで、Chatworkがどういうアーキテクチャで乗り切ったかでいうと、「Apache HBase」、「Apache Kafka」といった分散システム。あとはアプリケーションレイヤーにAkkaの分散システムを導入することによって、この難局を乗り切れました。

Growthフェーズの課題からの学び

当時の学びですが、大きく分けて3つかなと思っていて。やはりプロダクトステージに応じた積極的な技術投資の必要性を、経営レベルで合意する必要があるかなと思っています。

ちなみに私は着任早々、このお金があまりなかったときに「この技術投資が必要だ」と言って、けっこう取締役会が荒れるところがありましたが、「でもやはりこれは必要だ」と言って、最終的には当時CTOの山本含めて納得してもらい投資ができたのは、プロダクトの今の根幹を支えていて、私としては意思決定してよかったと思っています。

とはいえ新しい技術を採択するところに関しては、やはりリスクが伴うと思います。そのリスクは付き合っていかないといけないと思うので、リスクと得られるベネフィット、利便性みたいなところのトレードオフをなるべく客観的に、いわゆるビジネスやテクノロジー以外のスタッフにもわかりやすく説明する必要があると思っています。

あとやはり新しいものを採用するところに関しては、現場のメンバー含めて、心理的にけっこうプレッシャーかかると思います。そういったところで、僕はワクワクする目標設定が責任者には必要なのじゃないかと考えています。

エキスパート土橋さんのインタビュー

このときの難局を一緒に支えてくれたエキスパートが、NTTデータの土橋さんです。土橋さんが弊社と一緒にどういうふうに乗り切ったか、エピソードについて紹介してもらえたらと思います。

土橋昌氏（以下、土橋）：みなさん、こんにちは。エヌ・ティ・ティ・データの土橋と言います。よろしくお願いします。エヌ・ティ・ティ・データの中では技術革新統括本部に所属しています。エグゼクティブITスペシャリストとも名乗っていて、基盤技術に関する専門家として前者を貢献する立場で、会社を通じてお客さまに技術を提供していく立場で仕事をしています。

プロジェクトが始まった当時、Chatworkさんに基盤技術者がたくさんいたかいうと、そんなにはいなかったということで、すごく苦労していたとうかがっていました。

そこで私たちが基盤技術の専門家として、当時、私と一緒に基盤技術周りの研究開発やシステム開発をしていたメンバーと一緒に、それらのメンバーをリードする立場で参画しました。

当時、並列分散処理の仕組みを、あらゆる会社、あらゆる組織の人が使う必要があったかというと、まだそういうところまではきていなかったと思います。

当時使っていた技術も、日本国内において全員が全員知っているような状況だったかというとそうでもないし、その技術の出来上がり方としても、まだ若い技術だったというか、まだ本当にゴリゴリ実装も変わっているような状況だったので、そういう中で技術を導入していくのは、やはり「これ大丈夫かな？」と思っているところがあったのではないかなと私も思っています。

もともとCQRSプラスイベントソーシングのアイデアをもっていて、事前に検証されていた。割とスクラッチでやっていたとうかがう中で、そのアイデア、ベースの考え方を一緒に紐解いていくと、そこに入っている原理原則や設計思想などが、例えばApache Kafkaや、Apache1ベースなどのプロダクトがもっている設計思想と、すごく親和性が高いなと考て、コンポーネントをうまく接合していくと、実はハマるのではないかと発想したのが最初のポイントでした。

私たちがKafkaやHBaseを使ったCQRSの仕組みをやったと話をした直後ぐらいに、Kafkaの開発者がたくさん所属しているConfluentという会社が、企業ブログに似たようなコンセプトの技術ブログが投稿されたりしていて。

当時、私たちいろいろな場所に登壇していましたが、やはり間違ってなかったと言うか、「このコンセプトは当時にとって先進的な取り組みだったのだな」というのはすごく印象に残っています。

と、同時に、、当時まだプロダクトの中では比較的若くて枯れてないような技術も、システムの中でソースコードレベルで解析しながらどうにか使っていたプロジェクトでした。そういった、若い、まだ技術も実装も変わっていっているような部分を、実際に開発している開発者自身からもフィードバックをもらったり、ディスカッションさせてもらうような場をそのカンファレンスの中で設けたりして、非常にエキサイティングだったことを覚えています。

“喉元過ぎれば”という話になるのかもしれませんが、すごくいいチームで仕事できたという実感が正直あります。春日さんに呼んでもらって、弊社のメンバーとChatworkのメンバーと全員で話したときに「あ、このメンバーが揃うと、恐らくかなりすごいところまでいけるぞ」と感覚を最初に思いました。

実際にやってみて、それを噛み締めたというか、かなり創造的なことができたので、「いいチームだったな」と思った反面、プロジェクトの打ち上げのときは「あ、終わってしまうんだ」と言ったらアレですが。ある意味システムとしてはこれからスタートしますが、「一区切りついてしまうんだ」というのがちょっと物寂しくと言うか、感動的だったなとすごく覚えています。

国内においては先陣を切っていたプロジェクトだと、私は今でも思っています。若い技術を自分たちで中身まで紐解いて、ちゃんと咀嚼しながら一番活きるところに活かしていくことができたプロジェクトだったのではないか。実際、結果としてスケールするシステムを実現できたのが、今みなさんのシステムを支えられる一番低いレイヤーというか、ベーシックな技術として組み込まれているというのは、エンジニア冥利に尽きると本当に思います。

（次回につづく）