こんにちわ。id:cw-tomitaです。
この記事は、Chatwork Advent Calendar 2020 - Qiita の21日目の記事です。
Advent Calendarシーズンももうすぐ終わりですが、入社して初めての年のAdvent Calendarでこんな記事を書いたな〜と、ふと思い出し、
この記事を書いてから３年という、何となくキリのいい数字を迎えたので、これまでの歩みを振り返りつつ、来年やろうとしていることの紹介しつつ、あわよくば、そういうのめっちゃ興味ある！って人にChatworkのことを知ってもらうきっかけとなることを期待して、当時の記事タイトル*1をオマージュ*2して、この記事を書いていきたいと思います。
tl;dr
- Chatwork自体も、そのインフラも、この３年でめちゃくちゃ色々と変化・進化しました
- 2021年は、アーキテクチャ刷新プロジェクトは動きつつも、まだ、そっちの不確定要素が色々とあるので、既存システムに対しての改善・運用のアクションも止めずにやっていく必要がある
- 専門性を高めてこれからのChatworkの更なるスケールを支える次世代アーキテクチャを構築したいエンジニアも、雑食で色々と触りながら、少数精鋭でスピーディーに今の本番環境を改善していきたいエンジニアも絶賛募集中！
2017年末からの変化
３年も経つと、さすがに色々な変化があって、それらをまとめ出すとボリュームが大変なことになるし、既に別記事で色々とまとめてきてますので、この場では代表的な記事のリンクを置くだけにとどめておきたいと思います。
- １年半前に書いた、SRE部での活動まとめ
- PHPアプリケーション部分をKubernetesに置き換えた話
- Kubernetes基盤の話
- メッセージ検索機能のリプレイスの話
また、全体を俯瞰するという意味では、最近更新されたAWS事例にある、id:cw-ozaki作の構成図が、極めて忠実に現状を表現していますので、ご興味ある方は、是非こちらもご覧いただければと思います。
(こういう構成図、中々手が回らない所ではありますが、定期的にちゃんと作っておくと、進化具合が分かっていいよな〜と後から思うやつ。)
2021年に向けて
Creator's Noteを頻繁に読んでいただいている方の中には、こちらの記事をご覧になっていて、
検証中の新しいアーキテクチャをご紹介します！！ - Chatwork Creator's Note
"１年後のインフラ" ってことは、リプレイス案件の話？と思われた方もいるかもしれませんが、アーキテクチャ刷新プロジェクトはまだ検討段階なので、もう暫くの間、既存のシステムがバリバリ動くことになります。また、私自身が既存システム側の担当ということもあり、今回は既存システムに対しての話にフォーカスして記事を書きたいと思います。
また、３年前の記事は、re:Inventの発表に刺激を受けて、だいぶ空想ベースで書いた所もありましたが、今回の記事ではもう少し地に足のついた、具体的な話をしていきたいと思います。
やってきアイテム達
2021年のやってきアイテムとして考えているのは大きく以下の4つになります。
- EKSの定期version upgrade運用の洗練
- PHPアプリケーションのKubernetes移行の完了
- IaC(Infrastructure as Code)の強化
- HBaseのリプレイス検討・推進
注：ここに書かれるやってきアイテム達は、個人が考えたモノであり、正確な見積もり等は一切行っていないので、所属する組織の正式なロードマップとは完全には一致しません。
以下、１つずつ説明していきます。
EKSの定期version upgrade運用の洗練
詳細は↓で紹介されていますので割愛しますが、Chatworkのk8s運用は、マルチテナントのシングルクラスタ、Blue/Greenでのversion upを行っています。
最近、EKS 1.17 to 1.18のversion upを行って、概ね事前の計画通りに終わりはしたんですが、まあまあ工数がかかってしまっています。こういったversion up作業は定期的に行うことになるため、自動化・仕組み化によって、都度のversion upのための工数をもっと削減できる所はないか、、ってのを模索しつつ、より手順を洗練させていって、もうちょっとサクサクっとversion upが行えるような状態にもってきたいと考えています。
また、単に新しいversionに追随するだけではなく、新しく搭載された機能の検証・導入、モノによっては各アプリケーションへの展開といった所を、チーム間の責任分担、コミュニケーションパスを含めて最適化していき、活きたアプリケーション基盤運用を目指していく必要があります。
Kubernetes自体は新しいアーキテクチャでもアプリケーション実行基盤として使い続ける想定なので、ここで培った資産は、次世代システムの構築や運用でも確実に必要となるもので、しっかりと投資していかないといけない所でもあります。
PHPアプリケーションのKubernetes移行の完了
ここまで、何度かPHPアプリケーションのコンテナ化/Kubernetes化の話が出てますが、一部(残り２割くらい？)、従来のEC2ベースで動いているアプリケーションも絶賛稼働中です。二重運用は精神的にも知識のキャッチアップ的にも運用工数的にも優しくなくて、何１ついいことが無いので、しっかりと移行を完了させたい所です。
また、諸々の事情で、次に書く、"IaCの強化"に繋がる所もあったりもするので、費用対効果が大きい箇所でもあります。
IaC(Infrastructure as Code)の強化
Chatworkは去年の3月に9周年を迎え、来年10周年を迎えます。
もう令和なんだから、IaCなんて当たり前っしょ！って思われている方も多数いらっしゃることと思います(私も思いますw)が、Chatworkというサービスの開始とIaC関連のニュースを時系列で少し紹介すると、
- Cloudformationのサービス開始 → 2011/2/25
- Chatworkの開始 → 2011/3/11
- Terraform 0.1.0のリリース → 2014/7
となっていて、これを見ると、あ〜、これはIaCちゃんとできてなくてもしょうがないやつですね〜、、と、少し理解いただける所もあるのではないかと思います (きっちり移行できていないことへの言い訳...) 。 ということで、古のAWSリソース達の中には、まだ適切にterraform管理できていないものが残ってしまっています。。
また、Chatworkは、twelve-factor appなんていうオシャレな概念が有名になる前 (はてブのコメントが最初についてるのが2013/8)
[B! development] The Twelve-Factor App
から動いてるサービスなこともあって、AWSインフラのリソースIDやリソース名に依存するロジックがアプリケーションやデプロイの仕組みにがっつり埋め込まれていたり(詳細はややこしいので割愛)と、IaCするためにアプリケーション側やデプロイの仕組みにも大きく手を入れないと、、な所もあったりで、こういった障壁もあって、理想とするIaCの状態には持っていききれていない状態です。
これまでは、この状態でもそこまでの不便はなく回ってきたということもあって、そこまで優先度が上がることなく、現状維持できてしまったわけですが、以下の理由からここにも注力していきたいと考えています。
- 開発組織が大きくなって、並行して様々な開発が行われている中で、環境の再現性・ポータビリティが低いことがボトルネックとなるタイミングが出てきた
- システムのリプレイスをするにしても、独立した検証環境で、長期間に渡っての既存システムとの繋ぎ込みを行いたくもなることもありそうなので、先手を打って、既存システムのポータビリティーを確保しておきたい
- システムリプレイスの時は基本全てがIaCになるが、どのようなモジュール構成にして、どのようなフローで定義の追加・本番適用していくのがいいのか等のノウハウが組織内に蓄積されておらず、凄く扱いづらいものを作ってしまうことになるかもしれない。構成を熟知している今のシステムで、素振りをした上で、リプレイス案件に臨みたい
先に書いた通り、旧来のデプロイシステムとAWSインフラの依存を断ち切らないとならないので、まずは、全てのアプリケーションをk8sに移行し、既存のAWSインフラとの依存を持ったデプロイシステムを完全に刷新した上で進めていくことを想定しています。
HBaseのリプレイス検討・推進
現状、SRE部の守備範囲はかなり広範囲に渡っていて、その中で自前でホスティングしているデータストレージの自前運用は中々に重たいものがあり、以下の記事で紹介したようなupgradeはやったことありつつも、
３週間で出来たEvent SourcingでCQRSなアーキテクチャ上でのHBaseのupgrade - Chatwork Creator's Note
運用体制としては十分なものとは言えない状態が続いています。 そして、2017年版の"１年後のチャットワークインフラの話"の記事は、以下のような文章で締め括っていますが、
Falconリリースの際は、任せられる餅屋が見つけられなかったので、自分たちが餅屋になろう！と、新しい要素を大量に取り入れつつ、様々な挑戦をしました。それから一年が経過し、今回のre:Inventのたくさんの発表を見て、任せられそう、というか、自分達よりもすごく上手にやってしまいそうな餅屋(managed service)がチラホラと出てきたようなので、プロダクトが次に進むためにも、また個々のエンジニアとして生き残るためにも、そういう部分は餅屋に任しちゃって、自分達は新しい分野の餅屋になろう！という思いから、色々と想像してみました。
ここのベースの考えはあまり変わることなく、また、新しいmanaged serviceの誕生や進化などは目まぐるしいものがありました。
Falconがリリースされたのは2016年の年末で、アーキテクチャの検討自体は2016年の序盤に行われていますが、約５年も経過しているわけなので、今の状況を前提に改めてストレージ選定をすれば、他のものが最適であるという結論も十分にありうるのではないかと思います。
また、先に上げたHBaseのupgradeの手法然り、↓の手法然り、
チャットメッセージ周りがCQRSな作りになっているメリットを活かしてのデータマイグレーションは過去に複数回経験しており、このため、どんなストレージを使うにせよ、０ベースで考える部分は少なく、「データマイグレーションはBiryani PJの時のをベースにしつつ、httpのinterfaceを保ったままバックエンドを切り替えたread-apiを準備して、Carbon Xの時の要領で切り替えを」、、というような表現でメンバー同士では移行プランのイメージがサクッと共有できて、足りないパーツに関しても大体認識が合ってる状況にあり、ここの挑戦への土台は整っていると言えるのではないかな〜と思います。
アーキテクチャ刷新が動いている中で、この部分にどこまで工数を投入するかというのは、色々と意見が分かれるだろうし、しっかりとした検討は必要になるとは思いますが、移行に工数を使うことで短期的には遠まわりに見えても、この部分の憂いをしっかりと断ち切って、刷新プロジェクトに気兼ねなく人を投入できる状態を作ることが、中・長期での人の配置の最適化という面ではプラスになるのではないか？と個人的には考えています。 (要・詳細な試算)
もう１点、刷新アーキテクチャが動いてる中で、既存システム側を担当するとなると、一般的には、新しい技術的チャレンジを行えるチャンスは少なく、多くのエンジニアにとってモチベーションの維持が難しい状態になってしまう、、ってのは十分に起こりえる懸念ポイントかなと思っています。思いベースな所になってしまいますが、既存システム側で、敢えてこういう不確定要素を含んだ技術的難易度の高そうな案件を掲げてやりきること自体に大きな意味があると考えるし、しかも、それが刷新プロジェクトに戦力投入することに繋がるってのは、とても良いシナリオではないかな〜と思うので、しっかりと計画・遂行したいやってきアイテムの１つです。
2021年末の状態
ということで、来年末にこれらのアイテムが終わっていると想定すると、１年後のChatworkのインフラは、
- 定期的なEKS version upを少ない工数で回し続ける体制・仕組みが確立している
- 全てのアプリケーションがk8s上で動いている
- システム全体がIaCで管理されていて、AWS内であれば、アカウントやregionを気にすることなく、完全な環境のポータビリティを持っている
- HBaseのリプレイスが完了していて、次世代アーキテクチャ到来まで、メッセージのストレージ周りに大きく工数を割り当てる必要がない
という状態になります(予定) 。 めっちゃイケってるっぽさ！
注：ここに書かれるやってきアイテム達は、個人が考えたモノであり、正確な見積もり等は一切行っていないので、所属する組織の正式なロードマップとは完全には一致しません。
まとめ
３年前の記事をオマージュしつつ、来年末に向けての想像を書き散らしてみました。
ここまで読んできて、Chatworkの開発舞台は、アーキテクチャ刷新PJ動かしながら、既存システムにここまでの改善を加え続けられるほどに、Chatworkは戦力が豊富なんだな〜と感心された方もいるかもしれませんが、残念ながらそういうわけではないです💧
ということで、ここに書いた想像を現実のものとするために、専門性を高めてこれからのスケールを支える次世代アーキテクチャを構築したいエンジニアも、この記事で紹介したようなアイテム達を雑食で色々と渡り歩きながら、少数精鋭でスピーディーに今の本番環境を改善していきたいエンジニアも、(私的には特に後者を)空前絶後に超絶絶賛大募集中です！！
