はじめに
はじめまして、サーバーサイド/インフラあたりを見ているエンジニアの佐藤です。
ここまでインフラ関連の話があまりなかったようなので弊社のインフラ構成とデプロイ事情についてご紹介します。
インフラ構成
まずはデプロイ事情の前にざっくりとしたインフラ構成からです。
弊社では主にAWSを利用しています。
簡単な構成は下記図の通りとなっています。
他のマネージドサービスやGCPも利用している部分はありますが、今回は割愛させていただきます。
- Web
- サービスが稼働しているサーバで、NginxやRuby on Railsが動作しています。
- AZ2つにそれぞれ用意しており、AutoScalingを用いて柔軟に台数を調整しています。
- Batch
- 定期実行が必要な処理が動作しています。
- cronが現役で動いており、ジョブ数も多くなってきているのでジョブスケジューラの導入を検討したいところです。
- Worker
- 主にリアルタイム性の必要のない非同期処理だったり、push通知など大量のジョブをこちらで実行させています。
- 最近AutoScaling対応しました。
- MongoDB
- メインで利用しているDBです。
- MongoDB4.0からtransactionが導入されているので、ぜひバージョンアップして使ってみたいです。
- RDS(Aurora Mysql)
- 現状利用しているMongoDBのバージョンにtransactionがないため、課金周りなどのtransactionが必須となる処理のために利用しています。
- Elasticsearch
- 投稿リスト表示や検索処理周りで利用しています。
- EC2上で立てて運用していますが、所々課題があるのでマネージドサービスのElasticsearchServiceを導入したいと思っています。
と、ざっくりとした紹介ではありますが、今回はこの構成の中で頻繁にデプロイが必要となるWebサーバのデプロイフローについても紹介していきます。
デプロイフローについて
弊社ではBlue/Greenデプロイを採用しています。
大まかな流れは図の通りになります。
- Jenkins上からデプロイジョブを実行
- releaseブランチに対してコードのマージ命令
- マージされたコードでWeb Serverの準備開始
- 準備完了後BlueからGreenへ参照を切り替える
- 待機時間(※)終了後、起動されているWeb Serverを終了させてジョブが完了
※ 切り戻しに備えて一定時間待機させている
事前に各開発者が機能の実装を完了させ、GitHub上でコードレビューを行います。
動作確認等の最終チェックが済むとデプロイ可能になり、図の①を実施します。
あとは自動で順序通りに進んでいきフローが完遂されるという流れです。
切り戻しの際はデプロイジョブを停止させ、同じくJenkins上にある切り戻し用のジョブを実行します。
経過時間が30分未満の場合は、Blueが残っているため速やかに切り戻しが完了します。
それ以降は対象コードをリバートして通常デプロイで切り戻しします。
※ Batch/Workerについては、そこまで複雑ではないので割愛します。
影響が大きそうなリリース時に採用している手法
各種ミドルウェアのバージョンアップなど規模の大きな変更の際はカナリアリリースを採用しています。
直近ではRubyのバージョンアップ時に採用しました。
バージョンアップ済みのWebサーバを1台用意してELBへ接続し、1週間ほど動作させます。
問題なければ全Webサーバをバージョンアップ済みのものに切り替えます。
この手法を採用することで、最小限のリスクで本番環境での動作確認が可能になり大きな障害を回避できます。
また、まだシステム的にカナリアリリースの実施が確立できていないので、より実施しやすい仕組みを検討していければと思います。
改めて思ったこと
メンテンス性について
そこそこシンプルな構成になっているように思いますが、図の中で記載しているデプロイジョブが中々厄介者です。
Rubyで一連の処理が書かれているのですが、若干見通しが悪くメンテナンス性が悪いように感じています。
また、稀にJenkinsサーバがハングアップしていて、Jenkinsサーバ自体のメンテナンスも必要になっています。
マネージドに依存するのが良いのか悪いのか悩むところではありますが、AWSにはCodeDeployといったサービスもあるので、導入を検討していきたいと思っています。
デプロイ時間について
図の③で新しいWebサーバを用意しているのですが、ELBからの疎通確認完了までの時間が長く、1デプロイに6〜7分程度掛かっています。
うーん、長いですよね。
上記で記載の通り切り戻しの際、30分程度であれば速やかな切り戻しが可能ですが、それ以降だと通常デプロイをする必要があり多少の待ち時間が発生します。
遅れて障害が発生することもあるので、一定時間経過後でも速やかに切り戻しできるような仕組みがほしいところです。
参考までに他社の事例ではデプロイ時間が数十秒〜1分程度で、弊社より何倍も早く完了するみたいです。
このあたりのデプロイ高速化を見習って対応していきたいなと思っています。
まとめ
以上、ここまで簡単に説明してきましたが、メンテナンス性についてやデプロイ時間の改善などが未対応なものがいくつかあります。
新しい技術を取り入れてうまいこと運用しているサービスもよく見かけます。
モダンな技術を取り入れてインフラ面でも技術的な負債をなくし、管理のしやすい環境作りを心がけていきたいです。
まだまだ課題はたくさんありますので、一緒にインフラ改善をしてくれるメンバーも募集中です！
よろしくお願いします！
弊社では一緒にプロダクトを改善していただける仲間を探しています！
こちらでお気軽にお声がけください！
