こんにちは。 Garoon開発チームの洲崎です。
Garoon開発チームを紹介する全5回の記事も今回が最後です！
- Garoon開発 日本チーム全体
- セキュリティ: ❄️Yukimiチーム❄️
- リリース: 🌸Hanamiチーム🌸
- パフォーマンス: 🚄Nozomiチーム🚄
- インフラ: 🌙Tsukimiチーム🌙 <-- 今回はコレ！
今回はGaroonのインフラ移行するTsukimiチームの紹介です！
何をするチームなの？
Tsukimiチームは「Neco移行」と「クラウド関連の作業」を行なっています。
「Neco移行」とは自社で提供しているクラウド環境の基盤変更です。 全社的にKubernetesで動くNeco基盤に移行準備中で、Garoonもこの流れに乗ってNeco移行準備を行なっています。
Necoについては次をご参照ください。 blog.cybozu.io
クラウド関連の機能に触れることが多いことから、「クラウド関連の作業」も行なっています。 具体的にはElasticsearch対応やトラブル対応などです。
チームは9人（エンジニア6人, QAエンジニア3人）で構成されています。 必要な作業の検討から実装、テストまでを全てチーム内で完結させることができます。
Neco移行の難しさ
Tsukimiチームは「Garoonのお引越し作業」をしています。単なる載せ替えと思いきや、意外と大変です。
まず、コンテナでの提供になるのでGaroonが動くイメージを作らなければなりません。 外部リソースとの連携など、今までの動作環境とは異なる部分を変える必要があります。
単純移植でもいいのですが、Neco時代に最適な技術選定も同時に行なっています。 現行クラウド基盤ではPHP-FPMを利用していますが、「もっと適したものがないのか」検討したりしました。 過去の技術選定時には無かった選択肢もあり、悩みました。
他にもNeco移行では基盤変更以外にも大きな変化があります。 これからは我々ソフトウェア開発チームの対応範囲が広がり、よりインフラ的な領域も見ます。 製品知識を持ったメンバーが、製品都合に関わる全般の面倒を見た方が効率良いという観点からです。 これにより、今までにはインフラチームにお任せだったnginxなどのミドルウェアの設定などにも触れました。
先の話にはなりますが、お客様に不都合なく現行VM基盤からNeco基盤への移行が求められます。
このように今までの製品コードを主に扱ってきたエンジニアに「新しい知識と知恵」を求められるのがNeco移行の難しさです。
Neco移行の面白さ
一方でこの難しさは面白さでもあります。 「今まで触れることの少なかった領域に触れられること」がNeco移行（Tsukimiチーム）の面白さとも言えます。 中でも特に面白かった経験が3つあります。
まず、PHP構成の選定の経験です。 今選べる選択肢を並べて、メリット・デメリットを議論できました。 日々の業務ではあまり意識することのなかったPHPの構成について深く考えることができたのは良い経験でした。
次に、運用寄りの技術に触れられた経験です。 今まではnginxやネットワークの設定などは運用メンバにお任せだったのですが、この度、自分達で設定することになりました。 既に動いている環境の設定を参照したりすることで、理解しやすかったです。
最後に、新規でサービスを構築できた経験です。 Neco環境でGaroonを提供するにあたって、付随するサービスを新規開発する必要がありました。 こちらのサービスはGoで開発を進めています。 既存サービスの中に居ながら、新技術で新規開発できたのは良い経験でした。
このように新しい領域に触れる機会の多いです。経験を通して自分の対応可能範囲が広くなることは嬉しいですね。
Tsukimiチームの今
今、チーム内では大きく２つのプロジェクトが進行中です。
デプロイ・マイグレーションサービスの構築
お客様が契約したときにはお客様が利用できるように、各種リソースの割り当てが必要になります。
現行基盤でも同様の仕組がありますが、別チームが開発・運用してくれていました。 Neco移行後は製品の知識を持っているソフトウェア開発チームが開発・運用していきます。
現在、この仕組をGoで構築しています。要件定義から実装まで自分達で行なっています。
これに付随してお客様の全てのリソースをバージョンアップさせる仕組も作成しています。 Garoonには他のプロダクトと異なるバージョンアップ処理があり、検討の難所です。
非同期ジョブ実行の仕組の移行
Neco上で非同期ジョブを実行する仕組を構築しています。
現在はオンプレ時代から引き継がれるScheduling serviceと呼ばれる仕組で非同期ジョブを実行しています。 Neco環境では事情があって動かしにくいので、Workerと呼ばれる別の仕組で実行しようとしています。 Workerは登録された非同期ジョブを順に実行してくれるミドルウェアです。
非同期ジョブ実行の仕組は少々複雑になっています。 即時実行したい非同期ジョブはBackground Job daemonと呼ばれる他の仕組が仲介しているのです。
Workerで実行するようにすると仲介が不要になります。
新基盤に移るタイミングで簡単化しようとしています。
ただ、これがなかなか難題でした…
Background Job daemonで動いている非同期ジョブはリアルタイムで動き続けています。 アップデート中も絶えず非同期ジョブが追加・処理されるので以下のような課題を考える必要がありました。
- アップデート中に増える非同期ジョブはどのDBのテーブルに登録すべきか
- 増えた非同期ジョブは新・旧どちらのロジックで動かすべきか
- 移行に失敗した場合は復旧できるのか
今回は段階に分けて細かくアップデートすることで、安全にアップデートできるようにしました。 また機会があれば紹介させてください。
Tsukimiチームの今後
Neco移行は「細々とした機能対応」や「監視体制の構築」のようにやることがあります。来年ぐらいまで続きそうです。 安定運用のための仕組づくりがメインになってきそうです。
また、忘れちゃいけないのが「移行」です。 現在使っていただいているお客様にご不便かけないようにスムーズな切り替えも計画しないといけません。
やることはいっぱいありますが、新基盤に切り替えた先には良いことがあります。 リソースを適切に配置できるようになり、お客様体験の向上するでしょう。 他のプロダクトとの独立性も上がるので、リリースしやすくなり開発体験も良くなるはずです。
そんな新時代のGaroonを目指して、Tsukimiチームはこれからも頑張っていきます！
