Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

Kubernetes 導入における実践プラクティス(仮) The Beginning

こんにちわ。cw-tomita です。最近は「るろうに剣心 最終章 The Beginning」が公開されるのを心待ちにしつつ、これで健の剣心も見納めかという寂しさとが入り混じった複雑な気持ちで日々を過ごしています。

ということで、今回は、映画の公開9日前に開催されるChatwork Dev Dayの中から、私も所属するSRE部からお届けする「Kubernetes 導入における実践プラクティス(仮)」の The Beginning を書こうと思い立ち、筆をとった次第です。 lp.chatwork.com

本編だけでも十分に楽しんでいただける内容になるかとは思いますが、40分という限られた枠の中で、てんこ盛りの情報をお届けすることになりそうで、視聴いただく方々が消化しきれない可能性を少し危惧していますので、この記事を事前に読んで準備いただき、当日のコンテンツをより深く楽しんでいただけれたら幸いです。

想定ターゲット

"今の Chatwork と同程度の規模 or これから Chatwork くらいの規模になってくる会社で Kubernetes 運用に関わる人 / 興味のある人" を想定しています。
(Kubernetesって何?美味しいの?っていう方や、逆に数百台、数千台のKubernetes clusterをバリバリ管理してるぜ!って方にはあまり刺さらないかもしれませんが、もしかしたら何か発見があるかもしれないので、そんな方も是非、視聴いただければと!w)

アジェンダ

Immutable cluster に対する定期 version upgrade 運用戦略

前提

今回発表するChatworkでの取り組みを理解いただくにあたって、大きく2つの前提を把握しておいていただく必要があります。

  • EKSで提供されるKubernetesのversionは3世代のみで、それより古いversionはdeprecationされて、強制upgradeの対象となる。
  • version upの方法として、大きく、in-placeアップグレードとマイグレーションアップグレード(Blue/Green)の2つがあり、Chatworkで採用しているのは後者。
    • in-placeアップグレード = 稼働中のclusterをrolling upgradeしていく。
    • マイグレーションアップグレード(Blue/Green) = 新しいversionのclusterを新規構築してがっちゃんこ。
  • 後者の方式を採用すると、構築したclusterに対して変更を加えることが基本なくなるので、この方式で運用されているclusterは、一部界隈で、"Immutable Kubernetes cluster" と呼ばれる。(概念的にはImmutable infrastructureと同じ)
    • まだ一般的な用語ではなさそうだけど、きっとこれから定着していくはず!


また、この辺りの内容に関してはcw-ozaki作のこちらの記事にまとめられていますので、是非、ご一読いただければと!

creators-note.chatwork.com

version upgrade事情

ということで、やってることは、"Immutable Kubernetes clusterの運用"と、一言で表せるんですが、実際の所、clusterのversion upにあたっては、数多くのツール(e.g. ログ転送のためのfluentd、メトリクス収集のためのdatadog-agent)のインストール状況や設定を揃えたり、権限周り(e.g. clusterの操作ユーザ、node / pod に割り当てるIAMやsecurity groupの設定等々)を同じ状態にする必要があったりと、clusterの再現性を維持するために、考慮することがたくさんあり、中々に大変な作業となります。また、Kubernetes / EKSとそれを取り巻くエコシステムも進化を続けているため、deprecatedになるものが出て対応が必要になったり、新しく出来た、より良い仕組みを取り込んでいくという取り組みも必要となります。
るろうに剣心映画版の10周年には及びませんが、Chatworkでは、4年半ほどKubernetesが本番稼働しており、EKS以前はkube-aws (現在はEOL)というツールを使ってclusterを構築していました。EKSは1.16から利用していて、1.17、1.18、そして最新の1.19(2021/5/10 時点)と間を空けることなくupgradeを行い、大きな事故なく(小さいのはあったけど)、ここまでやってこれているし、cluster自体の構成も、upgradeの手法も、回数を重ねる毎に洗練されてきています。
勿論、一筋縄でここまで来れたわけではなく、今も試行錯誤中の部分はたくさんありますが、その辺りの歴史や課題も踏まえて、ChatworkのImmutable cluster upgradeに関して赤裸々に紹介したいと考えています。


また、以下の記事で、cluster構築に利用しているツール、またcluster自体の管理に関するツールの話が紹介されているので、事前に一読いただけると、当日の内容をより消化しやすくなるかと思います。

ChatworkのKubernetesを支えるツールたち(2020年版) - Chatwork Creator's Note

Kubernetesをめぐる冒険、の後日譚 - Chatwork Creator's Note

Kubernetes CI / CD の構成例

先のアジェンダは、Kubernetes cluster自体にフォーカスした内容でしたが、clusterのupgradeに際しては、clusterが起動するだけではダメで、その上で動いているアプリケーションも新しいclusterで動かし、デプロイ作業を新しいclusterに対して行えるようにして、http requestを処理するようなアプリケーションではクライアントの向き先を新しいclusterに変える必要もあります。
また、以下のページにChatwork全体の構成図がありますが、

AWS 導入事例:Chatwork 株式会社 | AWS

現時点で10種類程度のアプリケーションがKubernetes上で動いていて、新しいアプリケーションも絶賛開発中で種類はどんどん増えていくので、全てをSRE部だけで全アプリケーションの移行を完結しようとすると、組織としてのスケールの壁にぶち当たってしまうため、どこかしらで線を引いて、他部署(Chatworkは職能別組織になっているため、サーバサイド開発に携わる部署)の人も巻き込んで作業していく必要があります。

このように、定期的なupgradeを伴うKubernetes cluster上で動かすアプリケーションのCI / CDの構築・維持には、技術的、組織的に解決すべき課題が色々とあり、Chatworkでも絶賛試行錯誤中な部分ではありますが、こちらに関しても、これまで体験してきた辛み、そこに対しての解決策、今後の展望などを赤裸々に紹介していきたいと思います。


ChatworkでのCI/CD周りに関して、全体を俯瞰する話は今回のイベントが初となります(近々、何らかCreator's Noteの記事もアップしたいと思います!)が、ルーティングをどのように切り替えているか、、という所に関しては以下の記事で紹介していますので、事前に一読いただけると、当日の内容をより消化しやすくなるかと思います。

PHPのレジェンドシステムをEC2からKubernetesに移行する話 その4 〜Kubernetesクラスタの更新戦略に合わせたアプリケーションの移行戦術〜 - Chatwork Creator's Note

AWS濱さんを迎えてのディスカッション

また、今回はゲストとして、AWSのSolutions Architectの濱さんにも参加いただきます。濱さん、日頃あれこれと相談させていただいており、とても頼りになる存在です & 改めまして参加をご快諾いただき、感謝感謝です。 日々、様々なコンテナ事例に携わり、EKS利用/検討中ユーザの悩み所を知り尽くしている濱さんから、Chatworkの事例について深堀りいただくことで、視聴いただく方々に役立つ情報を届けられると良いな〜と考えていますし、また、第三者視点での質問・突っ込みをいただくことで、自分たちの取り組みついても何か改善のヒントが得られるのではという期待をしていたりもします。

(あんまり関わってい中の人からの)雑感

と、あれこれと、少しどやり感を醸し出しながらあれころと書いてきましたが、私自身はこの辺りの取り組みはほとんど関わっておらず💧 Dev Dayの発表者である、cw-sakamotocw-sasakiが中心になって作り込んでくれた仕組みでとなります\(^^)/

という所で(?)、逆に当事者ではない自分の雑感的な所も少し書いてみたいと思います。

話はがらっと変わりますが、私はほぼ日を作られた糸井重里さんが好きで、

ほぼ日刊イトイ新聞

糸井さんの書かれた文章やインタビューをあれこれと読んでいるのですが、強く印象に残っているエピソードとして、震災支援を長くやり続けるにあたって、人間の思いや行動はあてにならないので、それ用の予算を先にがっと抑えて、それによって仕組みとして、長期的に支援出来るようにした、というものがあります。予算に組み込まれているから、やるのを忘れることもないし、予算があるから、さあ、何をやろう?という所から始められると。多くの企業や個人が支援は長期的にした方が良いと思っているんだろうけど、多くの場合は単発で終わってしまうし、人間の思いや行動なんてそういうもんだから、ほぼ日ではそこに左右されないように、最初から予算に組み込んで仕組み化してしまったと。
(私が読んだのはこれではなかった気がするけど、似たようなことが書かれた記事を発掘)

もう7年は経っていますけど、うちは予算組みができていたからずっといろんなことができるんです

【イベントリポート④】糸井重里さんによる特別講演|fukko_design|note

そして、EKSのversion upについてあれこれと考えている時に、この話をふと思い出したのでした。
EKS導入にあたって、定期的なversion up(最低でも年に1回)が必要になる、、という話を聞いた時に、多くの人は、うっ...と思う人が多いかと思いますし、私もうう〜っっ * 10 、、と最初思いました。

でも、よくよく考えてみると、普段、システムの運用って大事だし、定期的に手を入れないとダメだよね、と口では言いつつも、(最低)年に一回のversion upに対して、うう〜っっ * 10 って思うのは何かおかしくないか? って思い始めたり、
仮に最近、自分が転職してきた立場だとして、
「このシステムはリリース以後、ほとんど触られておらず、当時の担当もいなくなってしまったんですが、2年以上安定して動き続けていて、全然手が掛からないんです(๑•̀д•́๑)キリッ」
って言われるパティーンと、
「ちょっと工数取られちゃうんですけど、最低でも半年に一回はcluster upgradeしながら運用してるんですよ〜」 って言われるパティーンとを脳内で想像すると、圧倒的に後者の方を健全で仕事がしやすそうだと感じると思うので、Chatworkでそういう世界観を目指していけるのはとても素敵なことだなと。

ほぼ日が予算という仕組みを使って、誰もがやった方が良いよな〜と思いつつ、実際はやる人が凄く少ない復興支援を長期間に渡って続けているように、EKSの古いversionのEOLを前提として、最初から絶対に必要な工数としてcluster upgrade用の工数を確保しておき、誰もがやった方が良いよな〜と思いつつ、実際はやる人が凄く少ない、活きたシステム運用を続けていくことができるのでは?とか、
また、当然のことですが、予算も工数も無尽蔵にあるわけではないので、ほぼ日が限られた予算の中で最大限に復興支援を工夫するように、Chatworkも限られた工数の中で、安全にcluster upgradeし続けるために最大限に工夫していく必要があり、そのチャレンジは、とても健全で、取り組み続ける価値のあるものではないかな〜と思ったりしていますし、実際、最近は1.17、 1.18、 1.19と、間を空けることなく連続でversion upを行うことができています。

私自身、Chatworkを含め、何社かでシステム開発・運用に携わってきましたが、ここまでライトにアプリケーションの実行基盤環境をがんがん更新していくってのは初めて見る光景で、(一見地味だけどw) めちゃめちゃ凄いことやってるな〜と感じていて、今回のDev Dayのこのコンテンツが、似たようなことをやりたいと思ってるけど、やり方がよく分からん!って人に届いて、何かが動き出せばとても素敵だし、さらに言うと、我々自身、一応、version upしてこれているとはいえ、改善したいポイントはまだまだ山のようにあるので、この取り組みをChatworkに入って一緒にドライブしていきたい!って思ってくれる人が現れて、カジュアル面談や選考に来てくれたら、さらにもっと素敵だなと、めっちゃ思ってます!!!w

hrmos.co

最後に

以上、「Kubernetes 導入における実践プラクティス(仮)The Beginning」をお届けしてまいりましたが、いかがだったでしょうか?この記事を読んで興味を持った方、また、興味を持たれなかった方も当日のコンテンツでは満足していただけると思いますので、5/26(水) 15:00 - 15:40 「Kubernetes 導入における実践プラクティス(仮)」を、是非ご視聴ください!!
また、当日はTwitter経由で質問を受け付けますので、開始前に、ここは気になるので詳しく知りたい!とか、終了後に、ここどうなってるの?/ ここをもっと深堀りして欲しい等々、質問/要望いただければ、当日の発表者であるcw-sakamotocw-sasakiAWSの濱さんがいい感じに拾ってトークに混ぜこんだり、Ask the Speaker from Twitterの時間でビシバシっと答えてくれますので、色々と投稿いただけると嬉しいです🙏

そして、万が一、参加登録していない方も、こちらから参加者を超絶絶賛大募集中ですので、お時間許す方は是非ご参加いただければと! chatwork.connpass.com