これは Chatwork Advent Calendar 2020 / Scala Advent Calendar 2020 11日目の記事になります。
こんにちは。サーバーサイド開発部の Scala プロダクトを開発運用する部署でマネージャーをしている、 hayasshi です。
前回は、Chatwork で実際に稼働している Scala プロダクトを紹介しました。
今回は、それらをどのように開発し、運用しているのかについて、ご紹介したいと思います。
開発プロセス
Chatwork では、標準化された開発プロセスはなく、各チームやプロジェクトの裁量に任せられています。
部署やチームは現在のところ、職能毎に別れた体制になっています。
また Chatwork では、プロダクトマネジメントをおこなう体制を敷いており、プロダクトマネージャー(PM)が検討起案した機能開発や改善施策に応じ、関連する部署、チームから人がアサインされ、プロジェクトマネージャー(PjM)を決め、プロジェクトとして施策を進める方式をとっています。
(このプロジェクト方式に課題感はあり、そちらについては後述します。)
それとは別に、自チームが担当してるシステムの運用タスク等もおこなわれるサイクルがあり、今回はそちらについてお話します。
サーバーサイド開発部 Scala のチームでは、スクラムをベースとした開発プロセスを踏んでいます。
現在のところ、厳密なスクラムではなく、タイムボックスを区切ってリズムを作り、自分たちで(ときには差し込みで)タスクの優先順位を決め、日々の開発を回しています。
朝会(デイリースクラム)
サーバーサイド開発部 Scala のチームでは、朝 10:30 過ぎくらいに朝会を実施しています。
内容としては、スプリントでアサインされたタスクに対し、取り組んでいることを説明し、達成するのに障害となっていることがあれば、別途時間を作り解決のための施策をとっています。
ふりかえり(レトロスペクティブ)
スプリントの最後にはふりかえりもおこなっています。
ここでは、スプリント内やこれまでの開発タスクを進めるなかで見つかった課題や問題への検討、対応するしないの判断、対応する場合は施策の検討をおこない、チーム内での開発プロセスの見直しや改善をおこなっています。
プランニング
ふりかえりの後、次のスプリントのためのプランニングをおこなっています。
日々の開発や運用、プロジェクトから発生したタスクを、チームの話し合いで優先順位を決め、次のスプリントでおこなうタスクを計画しています。
現在のところ、タスクに対する見積もりはおこなっておらず、期日のあるものやそのブロッカーになっているものから優先的に対応し、PjM と状況を共有しながらプロジェクトを進めつつ、チームのタスクもおこなうような状態となっています。
今後の話
上記のなかでも、「おや？」となる部分もあるかとは思いますが、現在の Chatwork の開発体制にあわせ、サーバーサイド開発部 Scala で実施しやすいやり方をとっています。
ただし、上述したとおり、プロジェクトベースの開発体制にも課題があります。機能開発の面では、機能がリリースされれば一区切りとなり、プロジェクトチームは解散となります。そうなるとリリース後にその機能を継続的にモニタリングし、改善をおこなうサイクルが構築できません。
またシステム運用の面でも、結局プロジェクトにアサインされたメンバーがその機能に詳しくなるため、チーム内で知識の偏りが生じ、「このエラーはあの機能のものなので〇〇さんに対応依頼しよう」というような流れになってしまいます。
上記のような課題感と、今後の Chatwork としても、プロダクトを中心に添えた開発体制、サイクルを構築したいと考えており、よりプロダクトの開発に適した体制方式に移行するための計画をおこなっています。
利用しているツールや技術
次に、開発をおこなうにあたって利用しているツールや技術をご紹介します。
タスク管理/情報共有、ドキュメント
タスク管理は Atlassian Cloud の Jira を、情報共有やドキュメントは Atlassian Cloud の Confluence をつかっています。
こちらは特に変わった使い方はしておらず、一般的な用い方で開発に利用しています。
(余談ですが、Jira と Confluence は全社的に導入されており、開発以外の社内の共有資料や議事録も Confluence が使われていたり、バックオフィスのタスク管理に Jira が使われていたりもします。)
開発環境、CI/CD
ソースコード管理に GitHub をつかった Pull Request ベースの開発で、エディタや IDE 、ターミナルソフトは個人で好みのものをつかって開発しています。社内では Intellij IDEA をつかって実装しているメンバーが多い印象で、会社として JetBrains All Products Pack のライセンスを各メンバーに渡しています。
ローカルでの開発環境は、各システム毎にdocker-composeをつかって簡単に構築できるようにしてあり、複数コンポーネントが協調して動作する場合でも end to end の確認を簡単におこなえます。
CI は CircleCI で統一しており、自動ビルドおよび自動テストを GitHub Pull Request 毎におこなうようにしています。
デプロイについてですが、Scala のアプリケーションはコンテナで運用されていますので、リリースバーションはコンテナイメージタグに付けて管理しています。CD には ArgoCD をつかい、デプロイ用の Kubernetes マニフェストを GitOps し、ArgoCD の管理画面から同期することでデプロイをおこなっています。
このあたりの開発環境の整備や Kubernetes へのデプロイ周りの諸々は、整備しきれているとは言えず、特に全システムを横断した検証環境をもっと気軽にメンバーがつかっていけるよう、整備を進めている最中です。
アプリケーション実行基盤(Kubernetes)
先に触れたとおり、Chatwork の Scala アプリケーションは Kubernetes クラスター内のコンテナ上で動作しています。
そのため、デプロイのための Kubernetes マニフェストは、SRE チームと協力しながら、主管はアプリケーションチームが担っています。
また、アプリケーションのスケールも、Kubernetes の HPA や時間ベースでの自動スケール等をおこなっており、その設定管理であったり、問題があった場合の Pod の入れ替えなどもアプリケーションチームが実際にkubectlをつかってオペレーションをすることもあります。(このあたり簡易なオペレーションであれば、ArgoCD上からおこなうことも可能ですので、今後 GUI ベースでのオペレーションになるかもしれません。)
運用とオンコール担当
最後にアプリケーションの運用と、緊急時のオンコール担当について書きます。
運用責務
先に記載した、Kubernetes に対するコンテナオペレーションもそうですが、アプリケーションに関する殆どのこと、実装〜検証、デプロイ、モニタリング、問題発生時の対応などは、アプリケーションチームで担当し運用しています。
もちろん、特にオペレーション周りはインフラストラクチャの動作の観点も多分に含まれてくるので、検証も含めて SRE チームとは多くコミュニケーションをとり、アプリケーションひいてはサービスを安定して提供できるよう、日々取り組んでいます。
メトリクス、アラート、オンコール
アプリケーションの各種指標(メトリクス)は Kamon というライブラリを用いて収集し、Datadog へ送信しています。
Datadog では、集めたメトリクスをつかい、可視化(グラフダッシュボード)をしたり、しきい値を定め、メトリクスベースでの問題検知をおこなうモニタリングをおこなっています。これをつかって日々のアプリケーションの運用(問題検知やスケール)の指標にしています。
また Chatwork では、SLA というかたちでサービスレベルを定めています。その品質を守れるよう、先程のメトリクスベースでのモニタリングからアラートを設定し、夜間や休日でも問題に対して検知、対応できるような体制を敷いています。
アプリケーションに関する部分のアラートオンコールは、アプリケーションチームも担っており、メンバーでローテーションを組んで日々オンコール担当を設定しています。
ただ、夜間や休日のオンコール担当はやはり負荷の高い役割です。各個人のそれぞれの事情的にオンコールローテーションに参加できない人もいらっしゃいます。
そのような負荷の高いオンコール担当のローテーションに参加してもらっているメンバーには、手当を出し、少しでも労に報いれるよう制度設定をしています。
さいごに
いかがでしたでしょうか？(何故か言ってみたかった)
Chatwork が Scala に取り組みだして約 6 年経ち、Scala の最初のアプリケーションをリリースしてから約 4 年が経とうとしています。
最初は開発してリリースして運用する、ということだけでも様々な問題課題がありました。いまでもまだまだ多くの課題は残っていますが、少しずつ、やるべきこと、今後の姿をイメージできるようになり、各部署と連携して整備を進めています。
また組織体制上の課題も、組織レベルで解決に向けた取り組みも行っています。
サーバーサイド開発部 Scala では、引き続きサービスを安定して提供するための運用とその整備、改善、より良いサービスとするための機能開発、将来の進化のための準備を通して、Chatwork をより良いものにしていきたいと考えています。
もし上記のような環境で一緒にやってみたい！様々な課題問題をなぎ倒してみたい！そのような方がいらっしゃいましたら、下記から是非エントリーしてみてください！一緒により良い Chatwork を創っていきませんか？
