見出し画像

スタートアップでデプロイ戦略勉強会してみたらいい感じだった

イナミ

はじめに

Acompany プロダクト部門 DCR チームのテックリード イナミです。
本記事は「#アカンクリスマスアドベントカレンダー2023」18日目の記事となります。

プロダクト部門はデータクリーンルーム製品の本格提供を開始しており、安定したサービス提供を目指してデプロイに関する勉強会を行いました。

弊社の勉強会の雰囲気が社内外で感じれたら嬉しいので、コメントと Q&A を含めて記事にしてみました。

弊社では優秀なメンバーによる様々な勉強会が開催されています！
ご存知ない方はぜひカルチャーデックを御覧ください。


勉強会の目的

AutoPrivacy DCR を開発するにあたって改めてデプロイメント手法について学び、各々が持っている知見を共有できるように勉強会にしました。

経験的にデプロイメント手法を議論する時間というの確保されにくいため、勉強会を通じた全体への知見共有が目的です。

時間を確保しにくいのは、実体験による知見が得にくいが、知見を持って決めたいと思うジレンマが理由だと思います。
教訓を得るために失敗して信用を落としながら改修作業するのは代償が大きすぎます。

またデプロイメント手法自体は直感的に SRE (Site Reliability Engineering) や運用に近い領域に感じます。
運用となると担当者も変わる可能性があり、リリースを繰り返し経験している知見が優先されやすく属人化してしまうのではないかと思います。

なぜデプロイ戦略が存在するのか？

そもそも稼働中のシステムに対して操作を行う場合は、サービスレベルへ影響が出てしまう懸念があります。

場合によっては取り返しのつかない障害を発生させてしまう大変危険な操作であることを理解しましょう。
AWS Well-Architected にもこう書かれています。

一般的なアンチパターン: システムが、より小さなリリースで更新できるように設計されていません。その結果、デプロイが失敗した際に、これらの一括変更を取り消すことが困難になります。
このベストプラクティスを確立するメリット: 変更の失敗からの復旧計画を立てることで、平均復旧時間 (MTTR) を最小限に抑え、ビジネスへの影響を軽減できます。
このベストプラクティスが確立されていない場合のリスクレベル: 高

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_plan_for_unsucessful_changes.html

一般的なアンチパターン: あなたは、新しい機能をアプリケーションにデプロイします。しかし、意図した通りに機能せず、影響を受けたユーザーからの報告を受けるまで問題を認識できません。
このベストプラクティスが確立されていない場合のリスクレベル: 高

https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/ops_mit_deploy_risks_test_val_chg.html

デプロイやリリースに問題が発生した場合はロールバックして延期も検討する必要があります。
変更前後で思わぬ落とし穴がいくつもあるので冷静に対処すべきです。

  • ロールバック自体にもダウンタイムや同様の問題が発生する可能性があるため、想定通りロールバックだけでもできるように事前に準備しなければならない。

  • リリースしてからしばらく経った後に致命的な問題が発生することもあるため、ロールバックが可能な間にできるだけ様々なパターンでテストしておきたい。

また昨今のデプロイ戦略は CI/CD に簡単に組み込まれており、Github Actions かクラウドベンダの CI/CD で迷っている場合の選定基準にもなるかと思います。

余談：デプロイ前日までに注意したいこと

  • 当日に慌てないためのロールバックの予行練習

  • 障害報告手順書を作成しておく

    1. 関係者への報連相の連絡リスト作成、文言テンプレートの用意

    2. 障害対応の一次報告、二次報告

    3. ポストモーテムによる再発防止措置

  • デプロイ手順書の徹底した読み込み

手法

Rolling Deployment

概要：既存の環境に新しいバージョンのコードを導入し、古いコードを廃止しながら徐々に新しい環境を増やしていく。
目的：徐々にデプロイする。Simple is best。

  • 簡単に構築できるソフトウェア例

    • AWS CodeDeploy (& ALB)

    • Kubernetes Deployment

      • Docker イメージを変更して apply するだけ

Blue/Green Deployment

概要：現在の環境に影響を与えず、分割された新しい環境に新しいバージョンをデプロイする。
目的：本番サービスを維持した状態で、(素のままでは主に開発者が)公開前の本番環境上でテストを行うことができる。

  • 簡単に構築できるソフトウェア例

    • AWS CodeDeploy & ALB

    • Argo Rollouts

    • Istio

    • GAE

Canary Deployment

概要：新しいバージョンを古いバージョンと一緒にデプロイして、新しいバージョンを使用するユーザーを慎重に制御する。検証を監視し、調整しつつ、徐々に人口を増やす。
目的：実際のユーザーの一部に新しいバージョンを公開して、ユーザの操作からアラートが出ないかチェックできる。

Canary Deployment (Canary Release) は新しいソフトウェアバージョンを一部の特定ユーザーに先行して公開し、本番環境でのテストを行った後、全体に展開する手法。

ブルーグリーンデプロイを基本にしており、特に新しい環境（グリーンバージョン）に特定ユーザーを導入することで実施される。新しいバージョンの影響を限定的に評価し、問題がないことを確認した後に本番環境全体に展開することが可能。

  • 簡単に構築できるソフトウェア例

    • AWS CodeDeploy & ALB

    • Argo Rollouts

    • Istio

勉強会ログ

Q&A

Q：Rolling Deployment はどのように後方互換性を意識しないといけない？
A：例えば機能Aが削除され、機能Bが新規実装され、過去から存在する機能Cが改修された場合を以下の手順に沿って考えてみるとわかりやすいと思います。

  1. 最初に、削除される機能は先にフロントエンドから削除しておく必要があります。機能Aを使えない状態にフロントエンドを更新しましょう。

  2. バックエンドはフロントエンドに新機能が登場する前にデプロイする必要があります。機能Aは残したまま機能Bが追加された状態にバックエンドを更新しましょう。

  3. バックエンドはフロントエンドに影響がない想定で機能Cをデプロイします。厳密には機能Cのデプロイタイミングは機能Bと分けたほうが障害の原因切り分けが楽ですが、一回のデプロイにも労力を要するのでまとめる場合が多いでしょう。

  4. バックエンドがデプロイ完了したらフロントをデプロイします。

1~3 は想像に難くないかつ Rolling Deployment 以外にも使いますが、よくトラブルが起きるのは 3,4 です。
本来は想定外の自体も起きることを覚悟しておく必要がありますが、ここでは頻発しやすい部分を抑えておきます。

3 が実行されている最中は機能Cの利用が始まりますが、インターフェイスに問題がないことが必須になります。
インターフェイスに問題がないというのは、API で言えば既存のパラメータは存続し、新規のパラメータは任意になっていることが条件です。

4 が実行されている最中は機能Bの利用が始まりますが、バックエンドがデプロイ前なのかデプロイ後なのかによらず、そもそも新しいフロントエンドと繋ぎ込みが行える状態であることを保証しておきましょう。

4 も 3 と同様にインターフェイスに問題がないことはもちろんですが、そもそも 4 の最中はバックエンドがデプロイ前なのかデプロイ後なのかを指定できずおみくじ状態になることが多いことを考慮したいです。
おみくじで大ハズレを引いたユーザからのアラートでしか観測できないエラーが起きることが容易に想像できるため、このおみくじを避けるために Rolling Deployment は後方互換性について言及される事が多いと感じます。

またより広義の後方互換性として、もしフロントエンド自体が古いバージョンを使えるようにするのであれば、機能Aをバックエンドから消さずに使えるようにしておかなければならないです。
ただしフロントエンドは古くてもよいかもしれませんが、機能Aはもう非推奨の機能であるという旨をバックエンドから返せるようにしておいたほうが安心であり、難易度が高くなるため安易に対応しないようにしておきたいですね。

Q：Canary Release はイメージとしては Rolling Deployment に近いと思う。Blue / Green Deployment は 0,100のような感じがする。
A：Blue / Green Deployment の拡張性の高さ次第だと思われます。

Canary Release を行うのであれば旧環境と新環境が混在するため Blue / Green Deployment を土台としてイメージすると問題が簡単になるかと思います。
ただし Canary Release を使うと純粋な Blue / Green Deployment ではなくなることは確かなので、バリエーションが存在するというくらいに留めておくのが良さそうに思いました。

ユーザに対する Canary のユーザの割合をどうするか、Canary のユーザが引く旧環境と新環境をおみくじにするのかユーザ特化させるのか、またおみくじの確率（Blue と Green を切り替えるタイミングと割合）が時系列でどう変化させるか、などどれだけ自由にできるかによるのではないかと思います。

コメント集

・デプロイ戦略は大事
・絶対起こさない！で終わらないの偉い
・過去のトラウマを思い起こさせるな
・ダブルチェックヨシ！
・定石がどんどんアップデートされそうな分野でもある

デプロイ戦略について

分かりやすい
ローリングに似てる気がする

Canary Deployment について

開発者専用の本番環境を作る感じか
Blue/Green すごい

Blue/Green Deployment について

ピックアップ

突貫工事で前日に急遽やろうと言い出した、かつ書籍もあまり豊富とは言い難い領域であるためネットから資料をかき集めながら試行錯誤でした。
温かい意見もらえて嬉しいです！

知見を更に深めて解釈されていて、素晴らしいメンバーとお仕事できていることを実感しますね。
このあたりの技術は普段考えることが少ないと思うので視野が広がれば幸いです。
意思決定への提言になり議論が活発化できたので目的は達成できたかなぁと思いました！

宣伝

Acompanyはプライバシー保護とデータ活用の両立を追求するデータクリーンルームをベースに、次なるデータ市場を拓くプラットフォームを展開しています！

Acompanyでは一緒に困難を乗り越えてくれる仲間を募集しています！

参考文献


この記事が気に入ったらサポートをしてみませんか？