00:00
こんにちは、エンジニアの博多家です。
こんにちは、エンジニアの三長です。
ゆるテクは、三長と博多家が緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい。いきなり本題に行きますが。
お願いします。
あの、ちょっときっかけ忘れたんですけど。
はい。
マイクロソフトのドキュメントを見る機会がありまして。
すごい突拍子も出てきましたね。
はい。
何だったかな。多分何かでマイクロソフト、ツイッターかなんかでマイクロソフトのドキュメントはいいぞみたいなの見たのかな。
なるほど、なるほど。確かにしっかり書かれてますよね。結構私も読んだ経験はありますけども。
マイクロソフトだからといって、別にAzureに特化したやつというわけでもないので。
はい。
なんでちょっと面白いねと思って、さーっと流し読みしてた中で。
はい。
ちょっと面白いドキュメントがあったんで、話してみようかなって思いました。
ぜひお願いします。
はい。いくつかあったんですけど、1つ持ってきたのがこれですね。今ちょっと2人で見てるところにあるんですけど。
シフトライトで実家の環境でテストするってやつがあって。
おー、なんかシフトレフトとかだとよくキーワードとして聞きますけど、シフトライトってあんま聞かない印象ですよね。
自分も全く同じで、シフトライトとな?と思ってちょっと見てみたんですよね、これを。
はいはい。
このリンクを開いてみると分かるんですけど、ガーッと書いてあって、だいたい読んだ感じの、要するにという感じで言うと、
はい。
リリース直前にテストをしていた結合テストとかっていわゆるそう言われるやつしますよね。
はい、そうですね。
で、それってだいたいのとこだと、本番環境に近いような環境を用意して、そこでテストするっていうQA環境みたいなのとかですね。
うんうんうん。
そういうとこでやっていたと思うんですけど、それを本番環境でやりましょうっていう、ざっくりそういう話かと思います。
本番環境、なるほど、はい。
どこかに多分そのメリット書いてあったんですけど、本番環境でテストすると次のことが可能になりますって書いてあって、
うんうん。
プロダクション環境の広さとか多様性を使える。
ほうほうほう。
はい、とか、あとはトラフィックの実際のワークロードって書いてあるんで、本番環境のね、実際のワークロードが来るからってことでしょうね。
確かに。
トラフィックの量もでしょうし、あとなんか3つ目にも関係するんですけど、
03:01
はい。
3つ目が時間の経過とともに変化する需要に応じたプロファイルと行動って書いてあるんですけど、
はいはいはい。
昼は多くて夜は少ないとか、
うんうん。
例えばですね、みたいなことかなと思っています。
今のその本番環境で実施すると得られるメリットっていう3つだったと思うんですけど、
うん。
あれですかね、割とこう、ちょっと非機能って表現が正しいか分からないんですけど、
うん。
よくそのエンジニアが見るパフォーマンスであったりとか、諸々のその非機能的な部分も分かるし、
もうちょっとプロダクト寄りな部分でいうと、
そのユーザー、使っているユーザーの特性とかも分かってくるっていう風に解釈していいんですかね。
だと思っています。
うんうんうん、なるほど。
いわゆるQA環境みたいな環境だと、そういうのを再現できない、もしくは難しいですよねって話かなと。
そうですね、確かにそうですね。
はいはい。
うん、かなと思っています。
で、その後もざっと書いてあるんですけど、
はい。
自分の解釈だと、あ、なるほど、シフトライトというのはフィーチャーフラグとか、
カナリアリリース、あとはそのフォルトインジェクションとかに代表されるカオスエンジニアリング。
はいはいはい。
らへんを総称した呼び方だな、これはと思いました。
あー、確かにやってることを考えると意味は近そうですね。
うん。
で、結構その実例とかも書いてあって、面白いなと思ったんですよね。
あ、実例も載ってたんですね。
実例っていうか、なんだ、具体的な話ですね。
そのフォルトインジェクションもそうですし、サーキットブレーカーの故障テストとかあるんですよね。
なんかめちゃめちゃカオスエンジニアリングじゃんって感じしますよね。
めちゃしますよね。
はい。
これは面白いなって。
うんうんうん。
で、その中で一個見慣れない聞き慣れない単語があって、なんじゃこれと思ったのがあって、リングベースデプロイメントっていうのがあったんですよ。
リングベースデプロイメント、初めて聞きましたね。
はい。これどういうものかっていうと、ちょっと間違ってたらあれですけど、この目的ごとにユーザーとインフラストラクチャをセグメント化して、その単位でデプロイしていくっていうものだと思っています。
ほうほうほうほう。
で、この目的ごとにっていうのが、ドキュメントのまま内容ですけど、導入によってもたらされたユーザーに影響を与えるバグのほとんどを検出。
とりあえずなんか目立つバグを検出したいみたいな目的が第一にここにあって、そのために対象のユーザーが内部の人たちにデプロイするとか書いてありますね、これは。
一見これを聞くと、まあフィーチャーフラグであったりとか、カナリアリリースがもたらそうとしている内容に近いようにも聞こえますけども。
06:09
うんうん、自分もそう思いました。これは、あの、ほら三田さんと同じ会社にいた時にフィーチャーフラグ使ってたじゃないですか。
はいはい。
で、あの時もデプロイする対象を選んでたと思うんですよ、フィーチャーフラグを。
そうですね、そうですね。
それが無意識のうちにこのセグメント化をしていたなっていうのはそう思いましたね。
確かにやってましたね。
で、その時もちゃんと目的があってやってたなと思って。
はい。
なんか例えばどのぐらい使われてるかとか、リングベースデプロイメントにもあるんですけど、スケール関連の問題を洗い出したいがためにちょっと大きめのとこに入れるとか。
うんうんうん。
やっぱりそういう目的別にフィーチャーフラグとかカナリアを使ってリリース先を絞るみたいな、これはものなのかなと思いましたね。
うんうんうん、なるほどなるほど、そうですね確かに。
それで言うとあれですかね、カナリアリリースを実現するためのハウとしてフィーチャーフラグがあるみたいな立て付けの方がわかりやすいですかね。
っていうのもありますかね。
うんうん。
ただこのドキュメントで見るとリングベースデプロイメントは実際デプロイ自体を対象のセグメントにしかしてないような感じがしますね。
じゃあ全てのセグメントで使われてるものが同じなんじゃなくて、同じでオンオフしてるっていうよりは本当にそこにだけ新しいアーティファクトがデプロイされてるみたいな感じなんですかね。
だというふうに認識しています。このページにはデータセンターとか書いてあるんで。
本当だ。
この小規模なデータセンターとか中規模または大規模のデータセンターって書いてあるんで、この単位でデプロイ自体をしてるんでしょうね、きっと。
これ少し細かい話になっちゃうんですけど、そういう風なリングベースデプロイメントってあると、何となく作るタイミングになった時のブランチの考え方とかにもすごく影響してきそうじゃないですか。
そうですね。どうやるんだろうこれ。
私の今までのイメージだと基本そういうカナリアに上がるものってメインブランチであったりとか、リリースするブランチに乗っていくものだなって思ってたんですけど、関連するセグメントにだけとかって考えるともうちょっと柔軟にブランチ切って柔軟に展開できるのかなって期待しちゃいました。
そうですね。少なくとも環境ごとにブランチを切ったりはしてないでしょうね。ステージング環境とかQA環境とかごとにブランチを切るっていうモデルではないでしょうね。
なるほどな。
それだと難しそう、これは。
09:01
確かに。でも初めて聞いた言葉ですね。リングベースデプロイみたいな。
こういう名前がついてるんだみたいな。実際同じようなことは結構フィーチャーフラグとか使ってればやってると思うんですよね。
そこでいくとあれですかね。フィーチャーフラグとかを使う場合ってなんとなく自分たちが使ってるアプリ作ってるシステムに対してはフィーチャーフラグって印象強いんですけど、
例えばそもそも裏で使うクラウドのサービスごと変えたときとかはこのフィーチャーフラグっていう表現よりはこっちの方がしっくりくるんですかね。リングベースデプロイメント。
確かにもう丸ごとというか、違うとね。
はい。そもそも別物ができてるというか。
そうですね。そんな感じなのかもしれない。
これどういうモチベーションなんでしょうね。
例えばそのシフトライトっていう表現でこのマイクロソフトのドキュメント書かれてますけれど、シフトライトをお意識する前に前までは今話してたやってることは本番相当の環境でやってたんだけどコストがかかりすぎてしまうであったりとか、
あるいはコストをかけてたんだけど結局本番じゃないとわからないことが多すぎて、ROIあまり高くないよね。だからもっとシフトライトした方がいいよねってモチベーションなんですかね。
こうおっしゃるじゃないですかね。やっぱり特にエンプラ系のやつだと全然その本番環境と同等の環境みたいなのを用意できなくて。
そうですよね。
あまり意味がなかったとかそういうことなんじゃないかな。
なるほどな。
なんか前、ちょっと前にありましたよね。どこだっけ。銀行全銀システムだっけ。なんかが止まった気がするんですよね。
うんうん。
その時もそういう感じだった気がする。事前のテストで洗い出せなかったみたいな。
なるほど。
なんかやっぱそのコストの問題もそうなんですけど、そもそもどんなに頑張っても本番環境相当の環境は作れないと考えた方がいいかもしれないですね。
確かにそうですね。そこに対して本番テストをするためのエンジニアリング材料は今たくさん揃ってきたから、シフトライトできてきますよねって感じですよね。
そうですね。どちらにしろこれ同じことをするはずですもんね。リリースした後ちゃんと動いてるかとか、このリリースによって期待した効果になっているかとかっていうのは結局のところを確認するはずなので。
そうですよね。仮説立てたものの検証とかは結局大体のこと、実環境で実ユーザーに動かしてもらわないことには検証できなかったりしますもんね。
うんうん。なのでそっちの方向に進んでいくのは納得な気はしますね。
12:03
確かに。
で、その今の話みたいなことがRSGTであったっぽいというのを見たんですよ。
はいはいはい。
内坂さんが見たということなので。
はい、そうですね。ブロッコリーさんがRSGTで話されてたシフトレフトとシフトライトの両面から製品開発に取り組んだお話っていう発表を参加させていただいたんですけど、
全体を通して結構シフトレフトとシフトライトの話と、実際にブロッコリーさんたちが取り組んでいる事例というか、具体的なケースを紹介してくださったっていう感じでした。
そう、これ自分がこのマイクロソフトのドキュメントの方を見てから、このブロッコリーさんの方を見たんで、シフトライトってそういうのもシフトライトなんだって思ったんですよね。
もう多分同じ印象を抱いているかもしれないです。
はい。さっき言ったような、実装がその通りになっているかとか障害が起きないかとかそういうことじゃないですもんね。この発表で話されていることって。
そうですね。おっしゃる通りです。
私も自分の中で持ってたシフトライトのイメージって多分博多家さんと結構近いものがあって、障害が起こらないかどうかとか、そっちだけを結構イメージしてたんですけども。
今回のブロッコリーさんの話を聞くと、そういう観点でも確かにシフトライトのテストなんだなっていうので、ちょっと視野が広がったというか。
その中で具体的にあったのがどちらかというと、発表を聞いた限りだと、ユーザーに与える価値に結構フォーカスしたパターンのシフトライトだなっていうのが今回紹介されてた事例でした。
なるほどですね。このタイトルにもある通り、アウトカムを計測できるようなやつ。
ですね。いくつかの例、3つぐらいだったかな。3つ事例紹介してくださってたんですけど、1つはそもそもこれからやろうとしていることに対してログを仕込んで、実際に本番に出してみて、まずそこで効果検証してみましょうっていうパターン。
いいな、小さい。
私がこれまで経験してきた開発だと、あんまりなかなかログだけ仕込んでリリースしちゃいましょうって、あんまりいい顔されなかったなっていう印象があって。
なるほど。
どうせリリースするなら何か機能乗せないよみたいなことが多かったんですけど、今回紹介してくださったのは、それが本当にアウトカムを生み出せるようなものなのかどうかの角度を高めるためのログ仕込みで、本番にリリースして、実際こういうログ出ましたよね。
これやったほうがいいねっていうのを確認するっていうのが1つの事例でした。
15:02
いいな。
いいですよね。
今だと結構オブザーバビリティのツールとかも豊富になってきてるので、どうなんでしょうね。
私が抱いた印象としては、アプリにログを仕込むのって相当コアなというか、特殊なところを測定したい時なのかなっていう印象を受けました。
かなりピンポイントというか、ここっていう感じですよね。
大まかなレイテンシーであったりとか、APMって大体今ってオブザーバビリティツールで取れるようになってるんで、それよりももっと深いものだったりするのかなと思いました。
ですね。
っていうのが1つと、2つ目が確かおっしゃってたのが、ユーザーというか実際のオペレーションの様子を監視する、観察するのをShift Liteでやってます。
多分使った状態がどうなのかとかっていうところですよね。
Shift Liteと言いつつ、多分それってどうなんでしょう。
例えば、UXエンジニアとかがディスカバリーする時にも結構やったりすることなのかなって思ったりもしてます。
ちょっとここが自分の中でまだフワッとしてるのが、そういうのを多分UXのエンジニアもそうでしょうし、QAとかのエンジニアとかも一緒に見たりするものなのかなとか。
はちょっと自分の中でまだフワッとしてます。
確かになぁ。
実際でもこれやった経験ありますよね。
やった経験はありますが、その時にやった経験はあるものの、じゃあそれをShift Liteしたぜとかって思ったかっていうと全然そんなことはなく、
もう、なんていうんでしょうね、机上でアーダーコーダー行ってるより1回出して実際に関数した方がコスト少ないよねっていうところからやった感じですね。
なるほどなぁ。
確かに自分はこれを機能を出した後の確認という段階でやるよりは、
自分たちが考えているこういう機能があった方がいいんじゃないかの仮説を確認するというかのニュアンスで、作業の前にやるようなイメージでしたね。
確かに確かに。
こういう機能があったら楽なのかなって実際その辺の業務を聞いたりとか見たりとかして、
やっぱこういうのがあると良さそうだなってなるパターンだった気がしているんですけどね。
それがやっぱあれなんですかね。
今の実際の作業の前にって我々が話しているところも、
多分その作業自体がどういうことをやりましょうかっていうプランするところと、
実際形にしていくコードとかテストとかの部分じゃないですか。
そのプランの材料を集めるためのモニターとかディスカバリーが実はDevOps Loopの右側のところだったよってことなんじゃないかなって思ってますけど。
18:11
なるほどなあ、そういうことか。
はい。
っていうのが2つ目で、3つ目がこれもさっきの観察するに近いんですけど、
実際に自分たちが提供したものが本当にユーザーに対して課題解決できたのかどうかを確認するとか検証するみたいなのが事例として挙げられてましたね。
どうやって確認する感じなんでしょうね。
確認の方法も紹介してくださってて、
実際にリリースしていくつか試してもらう現場というかパートナーというかを募ったというか持ち込んで実際使ってもらってるところを見てたらしい。
なるほどなあ。
すごいなって思ったのがその使ってもらってるところを見るまでが3段階ぐらいあったみたいで、
1回リリースした時にまず自分たちが実際の店舗で試す。
感覚でいうと本番環境を使ったドッグフーディングみたいな感じなんですかね、きっと。
この時にやるのは実際に使っていただいてるユーザーの方じゃなくて自分たちがやってみるんですね。
みたいです。
なるほど。
おそらくそこでいろいろここはもっとこうした方がいいよねがあったのかもしれないんですけど、
次のリリースでそこの店舗スタッフの研修で実際試してもらう。
研修で。
これは使ってる現場のシステムによるんで必ず研修があるとかどうかわからないですけど、その事例では研修の中で試していただく。
それもOKというか、そこでさらにブラッシュアップされたら最後正式リリースっていうパターンをされてたみたいです。
なるほど。
試しに入れてみるっていう感じなのか。
そうです。
なんでちょっとここで書いてる内容がさっきはくたけさんが紹介してくれたリングベースデプロイメントなのかどうかっていうのは詳細は定かではないんですけれども、
そうやって結構徐々に現場に馴染ませていくみたいなテストをされてたみたいですね。
考え方的には同じというか目的があって、その目的に応じた範囲に導入するというかリリースするというかっていう意味では似てるかもしれないですね。
ですです。
素晴らしいなって思ったのが大事にしてる観点っていうところで、
作ってる側の気持ちでいくといかに障害を起こさないかってやっぱあるじゃないですか。
ありますね。
それはもちろん大前提としてあるとして、それ以外にも大事にされてるところが、
21:00
新しく提供したものの習得のしやすさであったりとか、運用操作のしやすさっていうところを指標としてテストされてたみたいですよ。
だから研修とかでやったりするんですかね。
おそらく同じことができても手順が多くて全然習得するまで大変なんだってなると、
それはユーザー体験としてって必ずしもいいとは言えないしってとこですよね。
それすごいな。それ分かるっていうか判断も難しそうですけどね。
大丈夫そうかっていうその基準。
ただその大丈夫そうかっていう基準自体難しいけど、
そもそもその大丈夫そうかを確認するためには実際使ってる人たちに使ってもらうしかないので、
むしろそこはもうレフト側でいろいろ考えすぎるんじゃなくて、
シフトライトして早めにフィードバックもらうっていうのが確かに効果的なんだろうなと思いますよね。
そうですね。いろいろあるんだな。
なんで結構シフトレフトとかシフトライトの話を言葉としてキーワードとしては知ってることは多いんですけど、
こういう実際の事例とかを交えて説明してくださったので、
こういうパターンもシフトライトなんだなとかがすごくイメージしやすくて素晴らしい発表だったと思います。
いいですね。
今日の話がシフトライトだったからシフトライトだけの話をしてますけど、
当日の発表はもちろんシフトレフト側も話をされているので、
ぜひ資料興味ある方見ていただくといいんじゃないかなと。
資料を自分は見てなかったですけど、
このプロポーザルのところに書いてある、
Testing in DevOpsっていうのは確かにそうだなって感じですね。
全工程でテストしてる。
すごく印象に残った言葉が、
テストはフェーズではなくアクティビティであるっていうフレーズを紹介してくださってて、
自分が同じぐらい衝撃というか印象に残ってた本で読んだ言葉として、
監視は役割ではなくスキルだみたいな表現があって、
それに近しいものを感じました。
そうですね。
自分の中では確かにテストは普通にどの工程でもやるイメージだったんで、
でもエンプラとか、それこそWaterfallとかでやってるところは。
感覚としてなんですけど、
多分そのテストフェーズっていう言葉を使ってた時って、
24:00
テストの言葉がすごく驚異な意味だったんだろうなって思ってて、
テストイコール書いたコードが自分たちの予想通りに動くかどうかみたいな。
でも実際のテストって言葉ってそういう意味だけじゃないじゃないですか。
あくまでコードが正しく動くかどうかっていうのは、
広いテストの中の一部分でしかないというか。
結構そこのテストっていう言葉の捉え方で全然変わってくるなって思いますね。
確かに。いいですね。フェーズではなくアクティビティか。
なので、我々はきっとこういうことやろうよって、
プランしたタイミングでこのやろうよってなった内容ってどうかなっていうのは
ちゃんと確認というかチェックするし、
やっぱり全ての工程においてテストってやってるはずなんですよね。
テストという単語が含む意味合いが広すぎるみたいな感じですね。
そうです。
じゃあ今日はこのとこかな。ちょうどいい。
今回はマイクロソフトのDevOpsドキュメントと、
あとRSGTで見たセッションのお話をしました。
感想などは、ハッシュユールテクをつけてポストをお願いします。
Googleフォームからも送れます。
今日はありがとうございました。
ありがとうございました。
