FiNCのRelease Engineering
きっかけ
こんにちは、FiNC TechnologiesでSREをしています kenjiszk です。今回はRelease Engineeringについて書きたいと思います。最近行われた2回の勉強会でデプロイシステムの話やリリースについての話をしたのですが改めてまとめてみると色々と発見があったのでブログとしてまとめてみようと思います。
Release Engineeringとは？
SRE本によると、Release Engineeringとは以下の4項目の事です。
セルフサービスモデル
各チームがリリースプロセスをコントロールできているかどうか。
高速性
細かくて頻繁なリリースを行えているかどうか。
密封ビルド
ビルド処理に再現性があり、成果物に一貫性があるかどうか。
ポリシーの手順の強制
正しいリリースプロセスが策定されていてそれが徹底されているかどうか。
FiNCのシステムで求められることは？
前提として、FiNCのシステムはマイクロサービス構成をとっていて、複数のチームが複数のアプリケーションを運用しています。その上で、上記の4項目に関して様々な工夫をして来ました。
セルフサービスモデル
リリースプロセスの管理方法は、紆余曲折して来た過去があり詳しくは以下のスライドにまとまっています。
ちなみに、デプロイおじさんとはFiNC内製のデプロイツールのことですが、システムをECSにして全てのサービスでコンテナを利用するにあたり利用停止されたシステムです。
FiNCでセルフサービスモデルを意識し始めたのはこのECSへの移行のタイミングあたりでした、その背景にはマイクロサービスの増加と、それに伴うフレームワークや言語の多様化があります。
ビルドやリリース手順が多様化していったので各チームがリリース手順をコントロールしたいというよりは、SREチームが全てをコントロールすることが非効率になって来たという方が正しいと思います。
ビルドツールはJenkinsとCircleCIの両方が稼働していますが、リリースのステップは全てコードで管理されています。また、各チームの開発者が自由度を持ってビルド・リリースステップを柔軟に定義できるように、アプリケーション毎にJenkinsfileやcircle.ymlなどの設定ファイルが用意されています。
高速性
マイクロサービスの特性上、大量にビルドやリリースが走ります。そのためビルドツールの高速性と安定性を担保するための仕組みづくりが非常に大事になります。SREチームや独立した運用チームでありがちなのは、実際に開発を頻繁に行わないのでビルドツールの性能が劣化していたりビルドキューが詰まっている時に感度高く改善を行えないことです。
そこで、計測することを始めています。以下は、直近2週間に実行されたビルドの回数で、
- 通常は1日200弱くらのビルドが走っていること
- 10/23はおそらく大きなリリースがあり、そういった場合には300回ほどビルドが走ること
- 土日の多少はビルドが走ること
あたりがわかります。
こういった情報を見ることでシステムのスケールアウトやスケールインをどの範囲で行えば良いのか。どういった時にビルドのキューが詰まりやすいのか、実際に詰まっていたのか、といったことを考察できるようになります。
また、ビルドにかかる時間の測定も重要です。
上記は、主要なアプリケーションの過去2週間分の平均ビルド時間ですが、こういったものを長期的に記録することによってアプリケーションのビルド時間の劣化や、ビルドシステム自体の劣化を検知できるようになります。上図からは、紫と青のアプリケーションのビルド時間が非常に長いことがわかり、このアプリケーション開発効率が悪くなっていそうなことがわかります。
このように計測をメインで行うことで、高速性を担保できる体制を作っています。
密封ビルド
ビルド成果物の管理は基本的にDockerfileで管理しています。また、ビルドを行なって本番環境にデプロイするシステムも固定されています。
ポリシーの手順の強制
基本的に以下のフローを厳守しています。
- コードレビュー
- テストの実行
- テストが終了したコードをそのままdocker image化
- 検証環境にdocker imageをデプロイ
- 検証後、本番環境にデプロイ
今後やりたいこと
以上、FiNCのリリースシステムを見てきましたが、まだまだできていない部分はあります。
カナリアリリース
小規模なリリースを大量に行う場合には必ずしも必要ではないですが、言語やフレームワークのアップデートなどを行うような場合などはカナリアリリースをしたい場合があります。
ロールバック
サービス間の依存関係を持っている場合のロールバックや、dbのスキーマ変更が絡む場合のロールバックなど、この辺りをどう解決していくかは今後の課題です。
デプロイ手順の強化
各アプリケーションを跨ぐような機能の場合には、それぞれの開発断面でのQAが必要であり、その断面でのリリースが必要になります。現状のシステムではこういったリリースをシステム的に実現できないので、もう一つ専用の環境を作ることを計画しています。
プラットフォームとしてのリリースエンジニアリング
今回の話は全てサーバーサイドの話ですが、クライアントアプリケーションと合わせた場合にリリースサイクルやロールバックの扱いはより複雑になります。特にiOSの申請などがあると、どうしてもクライアント側とのリリースサイクルは合わなくなるのでプラットフォーム全体としてリリースをどう管理するかといった問題があります。
まとめ
リリースエンジニアリングはバックエンドのシステムや組織に対応して柔軟に変化する必要があるものだと考えています。
もしこういった作業に興味がある方いましたら一緒に働きましょう！
