00:06
はい、5月11日木曜日ですね。 時刻は朝9時17分になりました。
今日も技術的に読んでいくところだったんですけど、 ちょっと特殊な記事ですけど読んでいこうと思ってます。
はい、おはようございます。ひめめのkeethことくわはらです。
ではでは本日も朝活を始めていきたいと思います。
本日はですけどタイトルにあります通り、
本番環境へのデプロイに関する技術的な記事を見つけてしまったので、 それを読んでいこうかなと思います。
他にも技術的な記事がたくさんあってですね、 ばーっと見てたんですけど、
やっぱりソースコードが多い記事が圧倒的に多くてですね、
朝活の音読で配信するにはすごく相性が悪かったので、
ちょっと抽象的なものか、もしくは組織論とかチーム論とか、
そういう話になってしまうことが多かったので、
何かないかなと探してたらこういうテキストベースの技術的な記事があったので、 今日はそれを読んでいこうと思ってます。
はい、ではでは早速いきたいと思いますが、
レノアさんですね、おはようございます。ご参加いただきありがとうございます。
本日もダラダラっと配信を始めていこうかなと思っています。
はい、というところではでは早速本文を書いていきましょう。
新機能を本番環境に導入することはしばしば恐怖を伴うことというのがあります。
特にアプリケーションに多くのユーザーがいる場合、
ステンチング環境で新機能を希望通りに徹底的にテストするのは結構困難です。
また本番環境で発生する可能性のあるトリッキーなエッジケースを見逃ししまい、
ユーザーエクスペリエンスが損なわれるのではないかという不安も常にあります。
私は以前行政手続のデジタル化を目的としたプロジェクトに携わっていました。
プロジェクトのワークフローの一環として、ユーザーの微分証明書を外部APIですね、
仮にVerify Me Nowと呼びましょうと呼び出すことで、
認証する必要がやっぱりありました。
問題はこのAPIがあまりうまく機能しておらず、
サーバーエラーを介して多くのユーザーをブロックしてしまうということがしばしばあり、
それぞれの問題を調査して各ユーザーのブロックを解除するために、
私たちの側で手作業が必要だったことです。
その結果、APIプロバイダーに対する信頼が失われてしまいました。
残念ながら私たちはビジネスの都合上、このプロバイダーを使い続ければなければならず、
別のプロバイダーに乗り換えるという選択肢はなかったんです。
これは辛いですね。
ある日、VerifyMeNowのチームが、
私たちにこれまで私たちがよく遭遇してきた問題、多くの問題を解決するはずの
APIのバージョン2をデプロイしたことを告げに来ました。
しかし彼らは既に約束を破っていたため、
私たちは全てのトラフィックを一度にV2に移行すると、
ユーザーに大きな混乱とブロックを引き起こす可能性があることを恐れていました。
これが一応前田の話ですね。
まあそもそも不備があるというか、
よくうまく機能しないAPIにでも依存しなければならない環境って時点で割ともう
お察しって感じですけど、それがさらにバージョン2をいきなりリリースしたよって言われたらひにゃ。
03:04
まあまあ警戒心どころか、もう疑いの目しかないですよね。
まあ今そういう現場でまあ仕事をしていたと。
しているのかな今もね。わかんないです。
というとこですね、まあその続きちょっと読んでいきましょうか。
えーと、行き次はねぶさんですね。
おはようございます。ご参加いただきありがとうございます。
こんな感じいつも通りダラダラとやっていきたいと思います。
トラフィックを完全に移行する前に新バージョンが正しく機能することを確認するために
事前にテストする必要がありました。
一つの解決策としては新バージョンが正しく機能することを確認するために
数週間かけて厳密にテストすることも可能でした。
理想言えばありとあらゆるシナリオをテストするQAチームというのを採用することも一応可能でしたけど、
しかし移行に100%の自信を持てるほど時間をかけることはできませんし、
ユーザー数が意外と多いため、多くのHKSがテストされないまま実際に本番で起こってしまう可能性というのもあります。
まあね。
この中でリリースするって結構勇気いりますよね。
では次のセクションに行きましょう。
えー次はですね、段階的なデプロイメントとソリューションとしてのかなりリリースですね。
はい。
で、かなり、でけどかなりやリリースって確かに訳されること多いですね。
正しい読み方ってかなりやなんですかね。
これ僕いつもかなりリリースって読んでるんですけど。
まあいいや。本記事は訳通りにいきたいと思います。
かなりやリリースとは全ユーザーを移行させる前に新機能を一部のユーザーで使用し、その適切な機能をテストするための展開戦略になります。
また新機能と旧機能の分析を比較することもできます。
NPSとかユーザーリダフ率の比較であったりとか、新機能での成功や行動の評価などですね。
この戦略を実施すると、新機能にアクセスするユーザーの割合が問題が発生した場合は減少していき、そうでない場合は増加するというように何度か修正されることになります。
この戦略の利点の一つは一般的に行動変更をする必要がなく、したがって新しい展開を開始する必要がないということですね。
まあそうだよね。
それがある意味のかなりリリースの強みでありますからね。
で、これを確実にするための良い方法は、例えばかなりリリースに関連するすべてのプロパティを単純にデータベースに格納しておき、このデータが実行時に読み込まれ、修正が非常に安価にするようになることですと。
あーねー。
なるほど。僕これをデータベースに保存するって発想なかったけど、なるほど。
まあ無理やり感はありますけど、まあ分かりやすくかつシンプルだと思いましたね。
で、これには2つの大きな利点があります。
1つはこの統合の結果に応じて必要に応じて機能を有効化、もしくは無効化することができること。
で、もう1つは統合がうまくいき、最終的に全ユーザーに普及させたい場合、まあ影響を受けるユーザーの割合を徐々に増やすことができると。
で、続いて例のお話がちょっと出てきますね。
例えば、あなたがオンラインの自動車小売業者に勤めているとしましょう。
車のチェックアウトを安全にしたいんですけど、既にモバイル確認を使用していますが、より安全にするためにVerifyMeNow、APIですね、に置き換えることを始めたと思います。
06:00
で、この場合かなりリリース戦略がぴったりでしょう。
ID確認のプロセスの新バージョンを少数のユーザーのサブセットに展開し、ユーザーの行動と新機能のパフォーマンスを監視し、何か問題が発生したらすぐにロールバックすることができます。
新機能のパフォーマンスが良ければ、より多くのユーザーに徐々に展開し、全ユーザーにリリースすることもできます。
私の問題に戻りますが、典型的なユースケースは次のようなものです。
ユーザーは私たちのアプリケーションに接続し、管理上の要求を記入し、要求された書類をアップロードしてそれを提出します。
検証プロセスは非同期で行われ、ユーザーは数日後に自分の申請が受理されたかどうかというのを確認するために戻ってきます。
この非同期の検証中にVerifyMeNow APIというのが呼び出されます。
というのも、両バージョンの違いというのはユーザーには見えないため、一部のユーザーに対してこの機能をリリースしてもあまり意味がないです。
彼らの行動を分析しても正直意味はない。
結論から言うと、Kanaria Releaseというのは上手くいったかもしれませんが、ちょっとオーバーテクノロジーだったかもしれませんねというのがこの人のケースでした。
とはいえ、とりあえずKanaria Releaseのメリットというか強みというところはでも分かりやすかったなと思いますね。
続いてのセクションなんですけど、しつゆいせんさんとけんじさんですね。
おはようございます。ご参加いただきありがとうございます。
問題の記事をバタラバタラと読んでますと。
あとちょうど今のタイミングでスーさんですね。
ご参加いただきありがとうございます。
では続いてのセクションですね。
代替ソリューションとなるKanaria Deploymentのお話です。
さっきはリリースだったけど、これはデプロイメントなんですね。
Kanaria Deployment戦略というのはKanaria Releaseと非常によく似ていますが、主な違いは適用形態になります。
前の戦略とは異なり、この戦略というのは定義されたユーザーのサブグループに適用されるのではなく、
単にユーザーの一定割合に適用されます。またはトラフィックスプリッティングといったりします。
この解決策はバックエンドレベルの変更やユーザーが直接違いを感じないような変更に対して、
より適切でシンプルに実施できることが多いですと。
実際このタイプの場合、ユーザーからのフィードバックは追加情報を提供しないので、
このソリューションと組み合わせた内部監視でその有効性、パフォーマンスと鑑定性などを評価するには十分でしょう。
また一つの例です。あなたは複数のAPIとサービスで構成されるマイクロサービスベースのアーキテクチャのリード開発者であるとしますと、
あなたのチームは異なるデータベーススキーマを使用するAPIの一つの新バージョンを開発しました。
この場合かなりデプロイメント戦略を使用して、本番環境をリリースする前にトラフィックのランダムなサブセットで新バージョンをテストすることができます。
トラフィック分割を使用してトラフィックのごく一部を新バージョンに誘導し、そのパフォーマンスと信頼性を監視することができます。
新バージョンのパフォーマンスが良好であれば、全ユーザーに安全に展開するまで新バージョンに向けるトラフィックの割合を徐々に増やしていくことができます。
というのも先ほど説明したようにAPIの移行はユーザーエクスペリエンスに何の変化ももたらさないので、
特定のユーザーに対してリリースすることに何の価値も生まないからです。私たちの場合はある一定の割合にのみ移行を適用すれば十分でした。
09:00
だいぶ似てますね。ここまで厳密にデプロイメントとリリースというのを分けなくてもいいんじゃないかと思います。
組織の状況とか環境によって変えていけばいいと思いますけど、そんなに複雑でなかったりスタートであればどっちか片方でいいんじゃないかと思ったりしました。
結局は適用するサブグループの規模とかユーザーの一定の割合の話だと思うので、決めの問題な感じはありますね。
とはいえこういう分け方もあるよというのが一つのいい例でした。
続いては他の展開方法との違いというところですね。
まず最初、他の方法ではスタートですね。ABテスティングが真っ先に上がるらしいですね。
ABテストというのは同じユースケースに対して2つの異なるソリューションをユーザーに提供し、その効果を比較するという原理的にはよく似た戦略であります。
その違いはむしろユースケースにあります。
かなりデプロイメントはプログレッシブリリースの新機能のテストと検証に使用され、
ABテストは同じ製品の異なるバージョンを比較し最も最適なものを選択するために使用されます。
ちょっと目的が違う気がしますね。かなりリリースとかデプロイメントとABテスティングというのは。
パフォーマンスと計測的な可用性ソリューションというのが次の話ですね。
ローリングデプロイメント戦略というのがあって、
こちらはアプリケーションや機能の新バージョンをサーバーごと、もしくはクラスターごとにインフラストラクチャー上に徐々にデプロイしていくというものです。
そんなのあるんですね。ローリングデプロイメントという戦略があるんですね。
この戦略はダウンタイムやパフォーマンスの低下を抑えるのに役立ちますが、
ユーザーエクスペリエンスよりもアプリケーションのインフラストラクチャーの管理に重点を置いているため、
これまでのソリューションの本当の大対策とは実はなりません。
ブルーグリーンデプロイメントというのは、2つの本番環境が同時に重なり、ユーザーに影響を与えることなく、
新しいバージョン、グリーンをデプロイし、すべてがうまくいったことを検証し、
ユーザーのダウンタイムなしに基礎のトラフィック、現在はブルーですね、をすべて切り替えることができるようにします。
新バージョンに問題がある場合は、ダウンタイムなしで旧バージョンに簡単に切り替えることができます。
フィーチャートグルというのが、新機能を徐々に導入するための一般的な戦略になります。
このアプローチではユーザーにアクセスできないようにしながら、本番環境に新機能を導入することができます。
機能の準備が整ったら、関連する機能フラグというのを有効にして、ユーザーが利用できるようにします。
これにより問題が発生した場合は、新機能を簡単に無効化する柔軟性も生まれます。
なかなか良い話ですね。
単純にフラグだけ用意しておいて、いつでも環境をパッと切り替えられる。
向き先を変えるということですよね。
そういうようにしておくのが本当に良い話ですね。
とはいえ、それを裏付けるためにブルーグリーンのデプロイメントというのがあって、
それで支えられているというのが肝心ですね。肝要ですね。
まあでも良いですね。ローリングデプロイメント戦略というのは僕は知らなかったので。
これは新しい知見だな。
はいはいはい。
結局私たちはマイグレーションにカナリーデプロイメント戦略を導入することにしました。
12:01
もう一つは私たちのプロジェクトにはワークフローエンジンのカムンダというものがあるらしいですね。
ワークフローを通じてクライアントのアプリケーションの正常な動作を監視するために使用していました。
そこでカナリーデプロイメントの実装をこのワークフローエンジン上で可視化し、
その良好な動作の監視を容易にすることにできました。
そういうサービスとかツールがあるんですね。
最近はでも、モニタリング系の監視ツールというのもたくさんありすぎて、
結局どれがええんやという感じはしますけどね。
僕もその辺、あまり監視周りのところの設定とか環境整備したことがないので、
ちょっと僕は知見が弱いんですけど。
最近はニューレリックがまた盛り上がっている感じが僕の中でありますね。
いろんなところでニューレリック導入してますよってお話をいっぱい聞きますので。
結構ちゃんとソースコードベースでいろんなものを監視してくれますからね。
実際にユーザーですね、外側のユーザーがどういう行動をしているかみたいな解析もできますし、
ソースコード的な解析もできまして、ログの解析とかモニタリングもできたりするので、
ニューレリックさんかなり多岐にわたって強いなと思っていますが、
その分ちょっとお高いんですけどね。
やっぱり便利な分はお金が高いというのは仕方ない感じですけど、余談でした。
続いてワークフローエンジンでリリースを監視しましょう、モニタリングしましょうという話です。
前日したようにこれらのリリース戦略の最大の強みというのは、
新機能を徐々にリリースしその効果をモニタリングする柔軟性を持っていることです。
かむんだAWSステップファンクションまたはカスタムソリューションのようなワークフローエンジンをプロジェクトに組み込んでいる場合、
これはさらに便利になる可能性があります。
それはなぜでしょうか。
両バージョンで稼働しているインスタンスの数や両バージョンで発生しているインシデントを監視することで、
移行を視覚的に追うことができるからです。
そして起こりうる問題を素早く検知することもできます。
APIのV1からV2へのマイグレーションの例に戻りますと、かなりデプロイメント戦略を実装し、
ワークフローエンジン、私の場合はかむんだですけど、を使用すると次のようなワークフローができますので、
ちょっと画像がペッと張られていますけど、
ちょっとこれを音読すると分かりづらいのですみません。これは割愛します。
後ほどこの記事をツイートしますので見てみてください。
ブリックを使用するバージョンを選択すると、
指定された割合のトラフィックをバージョン2のルーティングにするだけで、
擬似コードでは次のようになります。
実際のもののワークフローエンジンや展開率をどのように保存したかなど様々な要因がありますけど、
一応これもソースコードがペッと張られていて、
単純にフラグが1個あって、それによって条件分岐をして、
単純にセットワークフローバリアブルというところで変数の値を書き換えて
向き先を変えるというようなことをやっている感じですね。
本当にシンプルな感じで、ソースコードもすごく短いんですね。
簡単に書き換えられるようになっているので、これはいい話ですね。
これによって両方のバージョンで実行されている現在のインスタンスの数を
簡単に視覚的に監視し、両方のバージョンで発生しているインシデントを確認し、
必要に応じて特定のエラーハンドラーを追加することができるようになります。
15:04
というところで最後でコンクルージョンですね。
特に期待通りに機能しない可能性のあるサードパーティーのAPIを扱う場合、
新機能を本番環境に導入するのにはリスクが高いなということもあり得ます。
Canaryのリリースとかデプロイメント戦略というのは、
新機能を全ユーザーに移行する前にサブセットのユーザーでテストすることで
この問題を緩和します。
これにより新機能のパフォーマンスをよりよく監視評価することができ、
何か問題が発生した場合には迅速にロールバックすることもできます。
またテスト時間を最小限に抑えることもでき、
アプリケーションの大規模な事前展開テストの必要性を低減することもできます。
このソリューションは場合によってはオーバーエンジニアリング度をまみなされることもありますが、
プロセス自体は非常に単純なもので、これらの戦略を実行するために
必要な投資はそれほど大きなものでもありません。
私の場合、Canaryデプロイメントとワークフローエンジンを組み合わせて
全てのトラフィックをAPIのバージョン2へ徐々に移行させるようにしました。
これによってその進捗を安全に監視することができました。
最終的にはその全てがスムーズに済んだので、
おそらく全てを一度に移行することも実はできたのでしょう。
これは蓋開いた話ですね。
しかしこの方法を使うことでプロセスに対する自信もつき、
テストにかかる時間も短縮することができました。
これらのガードを追加することは余分な行動を必要としないため、
コスト面でほとんど無視できるものでした。
したがって問題が発生しなかったとはいえ、
私はこの方法をぜひまた使いたいと思っています。
ということで本記事は締められておりました。
はい、とてもいいですねこれ。
今回はすごい成功事例の話だったんですね。
結構デプロイメントとかバージョン2への移行って
割とペインがあるなっていう話がスタートで
それをどう解決してきたかっていう記事の方が多いんですけど
今回のは何も問題なくスッと上手くいったっていう話なんですよね。
これはいい話だと思いましたし、
デプロイ戦略の話って
毎年毎年いろんな記事が出ますけど
結局ここに帰ってくる気は僕もしますね。
かなりリリースとかかなりデプロイとか
あとブルーグリーン戦略とか
ABテスティングは比較としてちょっと違う話かもしれないですけど
ビジネス的にやることも多いかありますよねって話で。
要は小さくリリースして小さく実証実験を重ねて
徐々にやっていくか
じゃあもうこれで大丈夫だから一気にドンってやりましょう
っていう2つが大きいと思いますけど
この方は今回は小さく小さくを繰り返す方の戦略に走ったってことですね。
それができるんだったらそれでいいと思いますけども
基本的にどんなサービスも
まずは小さく実証実験をするってのはやっぱり大事だと思いますね。
移行でエイヤーでドンってやっちゃうとか
やってしまうこともありますし
その方が早くユーザーに届けるため
後にかけるコストも減ってくるのでいいかもしれないですけど
その分リスクも大きいので
やはり最初は小さくっていうのを徹底したっていうのが
本当はいいんだろうなと思いますね。
あと別のなんですがリリース戦略じゃないですけど
カオスエンジニアリングって話があって
突然サーバーをドンと落とすみたいな
カオスエンジニアリングっていう方法があるんですよね
結構無理やり感があって
怖い面はあるんですけど
でもそういう後にもしかしたら起きる可能性があるっていうことを
意図的に起こすっていうようなテストの仕方もあるんですよね
18:02
そういうのも使ってみるといいかもしれないです
それができる環境であることが大前提ではありますし
そういうのをなかなかするのは大変だと思いますね
Netflixはそういうのをやってるってお話を前聞きましたね
だいぶ前にちょっと余談ですけど
どのエンジニアの方かちょっと忘れましたけど
Netflixにスクラムか何かを教えに行った方がいらっしゃったらしくて
その時に中の人に
今本番稼働しているNetflixの実際のサーバーですね
これの電源切ってくれとか電源コード引き抜けみたいなのを言われて
さすがに怖いじゃないですか
全世界みんなが使っているサービス
Netflixの本番環境のサーバーを落とせって言ったんですよ
怖かったけどむしろできるわけないじゃんって言ったんですけど
実際に手を掴まれて無理やり押させられたっていう話を聞いて
実際落ちたんですね
そうするとパトランプがバーンと光って
インフルエンジニアとかがバーっと何人か
そのサーバールームに入ってきたらしいですね
その時の日合わせはやばかったみたいな話を聞いたことがあるんですけど
本当に誰だったかすいません思い出せなくてごめんなさい
結果的にはNetflixさんと落ちた時のリカバリープランとかも
しっかり設定されていて
結局1分後くらいには復帰したんですねサーバー落ちても
かつサーバーが1個落ちたところで
全世界への展開はなるべく影響がないような環境になっているらしくて
インフルエンジニアの方が来たんですけど
サーバーのパトランプとか設定までバーっと見て
とりあえず復旧活動も入っているから問題ないなっていうので
パッと見てパッと帰られたらしいんですよ
っていうのでそういう風にちゃんと可用性まで
しっかり考えられたインフラ構成になっているっていうのが
Netflixさんらしくて
とても素晴らしい話だなと思いました
でもさすがに怖いですよね
いきなり本番の電源落とすとかサーバーの落とすみたいな話で
かなり怖いと思うんですけど
でもそれができてをやるっていう
これ一つのカオスエンジニアリングの形だなっていうのはありますけど
などなどいうところでデプロイに関する戦略とか
可用性とか小さくデプロイするみたいな戦略は
やっぱりすごく大事なことなので考えていきたいと思いますし
僕そのフロントエンドエンジニアなんですけど
でもだからといって別に領域違うからやらなくていいやっていうのは
僕なんかちょっと違うと思っていて
エンジニアっていうのは技術で問題を解決するためなので
必要であれば学ぶのはすごく大事だと思っているので
今後僕はそういう考え方です
他の人は別に考え方あると思うんですけど
僕はそういう考え方なので
今後もインフラはすごく苦手なんです
僕一番苦手なのはインフラなんですけど
こういうところはやっぱり
勉強し続けていかなきゃなっていうのは思ったりしました
というところで
最後余談で申し上げないですけど
今日の朝活はこれで以上にしたいと思います
明日はただにちょっと準備は全然まだ思いついてないので
もしかしたらまた組織論のお話になってしまうかもしれないですけど
興味があれば聞いてみていただければなと思います
じゃあ本日の朝活はこちらで終了したいと思います
改めて今日は
スーズさんと周佑泉さん
リブさん
ケンジさんと
レノアさんと
足立さんですね
弊社のスーズさんですね
ご参加いただきありがとうございました
じゃあ木曜日ですね
実質的な1週間のラストは今日だと僕は思います
金曜日はなかなかちょっと身が入らないんですけどね
今日をしっかり締めていけたらなと思います
それでは終了したいと思います
お疲れ様でした
