kubell Creator's Note

ビジネスチャット「Chatwork」のエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

１年後のチャットワークのインフラの話

Advent Calendar

こんにちは。インフラマネジメント部の id:cw-tomita です。 今年のAWSのre:Invent凄かったですね！！たくさんの驚きの発表があって、最近の技術イベントの中では際立って刺激的な内容だったと思いました。 興奮冷めやらぬ中、今回、発表された機能たちを反映させていくと、１年後のチャットワークのインフラはどのようなものになるのか？？少し想像してみたので、今日はその内容を共有したいと思います。

注：ここに書かれる想像は、個人のモノであり、所属する組織の正式なロードマップとは一切関係ありません。

現状

昨年末の巨大リリース(Falcon)による変化

チャットワークは昨年の末にFalconプロジェクトという大きなリリースを行いました。チャットサービスの根幹であるメッセージデータ部分の処理をごっそり作り変える大プロジェクトでした。この構成変更に関する詳細は、以下のスライドにまとまっていますので、興味のある方はこちらも是非ご覧ください。
speakerdeck.com

スライドにある通り、たくさんの要素が詰まった巨大リリースだったのですが、インフラから見た時の大きな変更点としては、

  • メッセージデータのstorageをAuroraからCQRSを使ったKafka + HBaseに変更し、Kafka/HBase/ZookeeperはそれぞれEC2上にhostingした
  • EC2上のPHPアプリケーションの一部を切り出してscalaのapplicationに置き換え、Kubernetes with kube-awsで浮かべた

という２点でした。 ざっくり言うと、hostingするミドルウェアの種類とEC2のinstance数がぐっと増えました。 図にするとこんな感じです。

f:id:cw-tomita:20171214185758p:plain

１年後のインフラ構成

大まかな方針

昨年のFalconリリースでは、scale outできるメッセージサービス構築という課題への自分たちが考える最適解として、自分たちで様々なモノをEC2上にhostingするという選択をし、大きく脱manged serviceな方向に進みました。
この場では、今からさらに１年後の構成を考えるので、振り子を逆に振ってみて、re:Inventで発表があった新機能を中心に、managed serviceを使う方に寄せて、構成を考えてみたいと思います。具体的にはEC2の数を減らすことを目標にします。 EC2の利用状況を大きく区分けすると

  • PHPアプリケーション (web + batch)
  • Kubernetes via kube-aws (controller + worker + etcd)
  • HBase
  • Kafka
  • Zookeeper

になるので、それぞれ、どうしていくかを考えます。

PHPアプリケーション

AWSではafrgateなるものがコンテナの中心にきそうなので、これにEKSを組み合わせる形になるのかなーと想像しました。 www.publickey1.jp PHPアプリケーション自体がまだコンテナ化されていないので、そこの対応から〜ということにはなりますが、きっと問題ないでしょう。また、kubernetesの運用ノウハウはそれなりに溜まっているので、ECSではなく、EKSにしたいです。

Kubernetes via kube-aws

PHPアプリケーションがEKS + Fargateになるなら、それに追随させてしまいましょう。EKSに関しては未知な所が多いので、現状のkube-awsベースのclusterとの比較が難しいですが、Audit Log、IAMを使った認証/認可、workerのscalingのintegrationなどなど、AWS managedならではの優位な点が出てくれるといいなーと期待しています。

HBase

ここは悩ましい所です。 １つ目の候補はAuroraにmulti writerという画期的な機能が出たので、これを使うことです。 www.publickey1.jp

HBase導入の大きな１つの要素として、書き込みがscale outできる点がありました。Aurora multi writerの"multi"が、どれくらいの"multi"なのかにもよりますが、re:Invent前に発表されたm4.16xlargeと組み合わせると、相当なスループットが期待されます。しかも、multi writerはregionをまたいで構築できるようになるそうなので、HBaseをregionまたぎで自分達でhostingすることなく、グローバル展開を視野に入れることができます。 multi writerの弱点は、同じrecordへの更新が複数マスターで同時に行われることだそうですが、
(参考: AWS re:Invent 2017: Deep Dive on the Amazon Aurora MySQL-compatible Edition (DAT301) - YouTube)
HBaseが扱っているメッセージデータは発言ユーザに紐づいたものであり、同一メッセージに対する更新/削除が、違うregionにホストされているwriterで同時に実行されるのは、相当なエッジケースであろうと思われるので、これは問題にならなさそうです。 また、Aurora serverless(サクッとscale up/downする)の発表もありましたが、チャットワークはビジネスでの利用が多く、また、現状では日本からの利用が多数を占めるため、日本のビジネスアワーとそれ以外の時間帯のトラフィックには大きな差があり、この機能を導入すればコストの最適化も図れます。HBaseはStorageとComputingリソースが密結合なので、今後もこのようなスケーリングを行える可能性はかなり低そうなことを考えると、Aurora serverlessはAuroraの大きな強みとなりそうです。

２つ目の候補はDynamoDB Global Tables。 www.publickey1.jp こちらでもAuroraのmulti masterでやろうとしていた、multi region構成は実現できます。conflictに関しては調べられていませんが、上述の通り、異なるマスターで特定のレコードに対する更新が行われる可能性はかなり低いので、問題なさそうな気がします。また、一緒に発表されたDynamoDB Backup and Restore機能や、ちょっと前からあるAuto Scaling機能など、最近の進化のスピードはかなりのモノがあり、AWSとして、ここに投資している感を感じることができる点も魅力ですし、HBaseの置き換えという視点で考えると、RDBであるAuroraよりもDynamoDBの方が、直感的にはフィットしそうな気もします。

あとは、コスト面や、諸々のユースケースとの付き合わせということになりますが、想像の中では完結しないレベルの話になってしまったので、ここでおしまいにして、どっちかを使う、って感じにしておきたいと思います。

Kafka

kinesisという手もありそうですが、今回は目立った発表はなかったし、ちょっと変化球 & よりタイムリーな所で、re:Inventに合わせてGAが発表されたConfluent社(kafka開発のleading company)のConfluent Cloudを使うことにしましょう。 www.confluent.io kinesisに乗り換える明確なメリットが見えてないので、既存のソースコードの資産をそのまま使えるというメリットはあるし、弊社はscalaエンジニアも多数在籍していますので、scalaで作られた、進化の早いオープンソースなプロダクトの上でワイワイやれる楽しさも捨てがたいものはあります。

Zookeeper

HBaseとKafkaは自分たちでhostingしなくなるので、不要になるかと思いきや、messageのID生成するアプリケーションがzookeeperを利用しているため、完全に撤廃はできません。でも、大丈夫です。EKSがあれば、その上でサクッとzookeeperを動かすことも可能そうです。(これがEKSのfargateモードで動くのか/いつから動くようになるのかは分かりませんが、そういう細かいことは考慮には入れません。) charts/incubator/zookeeper at master · kubernetes/charts · GitHub

これらをまとめると、以下のような図になります。
先のおおまかな方針のところで、↓と書きましたが、

具体的にはEC2の数を減らすことを目標にします。

なんと、自分たちで管理する必要のあるのEC2を0にすることができました！！構成図もとてもスッキリしましたね。

f:id:cw-tomita:20171214185739p:plain

まとめ

チャットワークは、社長が、座右の銘は"餅は餅屋"です、と言うくらいに、専門のことは得意な者に任せようという考えが根付いています。 blog.ecstudio.jp Falconリリースの際は、任せられる餅屋が見つけられなかったので、自分たちが餅屋になろう！と、新しい要素を大量に取り入れつつ、様々な挑戦をしました。それから一年が経過し、今回のre:Inventのたくさんの発表を見て、任せられそう、というか、自分達よりもすごく上手にやってしまいそうな餅屋(managed service)がチラホラと出てきたようなので、プロダクトが次に進むためにも、また個々のエンジニアとして生き残るためにも、そういう部分は餅屋に任しちゃって、自分達は新しい分野の餅屋になろう！という思いから、色々と想像してみました。

(再掲) 注：ここに書かれた想像は、個人のモノであり、所属する組織の正式なロードマップとは一切関係ありません。

チャットワークでは、AWSの最新機能を使いこなしつつ、何らかの餅屋にもなれる、一緒に１年後のサービスを作り上げていくエンジニアを大募集中です！！！

corp.chatwork.com