この記事は2019新卒 エンジニア Advent Calendar 2019の14日目の記事です。
前日に書こうとしたのですが、回線の調子が悪く開発が出来なかったため、当日になってしまいました。
今回はistioの機能を試してみる記事です。
環境構築編はこちら。
https://qiita.com/erb_owl/items/dfb322ceaecdb02952e8
kialiについて
istioをinstallした際にkialiというdashboardも入ってくるのですが、こちらがistio関係のmanifestを編集・確認する際に便利なので使っていきます。
例としてkialiを開いて、istio-configタブをクリックし、Virtual Serviceで絞込んでbookinfo(istioのデモアプリの名前)のVirtual ServiceのYAMLを開くとこんな画面になります。
ここに直接書いて反映させるのが一番楽なのでそれでやっていきます。やっていること自体はmanifestを書いてkubectl applyしているのと変わらないのでここらへんは好みです。
障害注入/FaultInjection
障害注入 はリクエストを遅延させたり、エラーを返したりさせる機能です。サービスが外部のAPIを呼んでいる際に、遅延やエラーが合った際の挙動を確認することができます。カオスエンジニアリングのためにも使えますね。
こんな形でAbortの設定を追加してみました。
50%の確率で本来のレスポンスの代わりにstatus codeが400であるエラーが返ってきます。実際に反映されているかPostmanを使ってリクエストを送ってみます。
200回のリクエストを送った結果がこちらです。
status codeが400かどうかでtestを書いたのですが、見事に約50%が400になっていますね。
遅延も試してみましょう。設定は以下のような形です。
20%のリクエストが3秒間遅延する設定です。こちらもPostmanで確認してみましょう。
ぴったり過ぎてもはや怪しいくらい20%のリクエストに遅延が発生していることがわかります。
Retry
リトライは文字通り、リクエストが失敗した際に再度リクエストを送る機能です。
こちらの機能を試すためには、ランダムにレスポンスを変えるサーバーがあると便利なので作成します。
今回は1:1の割合でstatus codeが200,500になるサーバーをRubyで作成してdeployしています。
require 'webrick'
server = WEBrick::HTTPServer.new({
:Port => 3000
})
server.mount_proc '/' do |req, res|
res.status = rand(2) == 0 ? 200 : 500
end
server.start
VirtualServiceはこうします。
リトライ処理を5回挟んでいます。
挙動を確認するためにPostmanでリクエストを送ってみます。
200回中5回、200で返ってきています。リトライ処理を5回した場合、1/2**6=1/64の確率で失敗することになります。
200回リクエストを送った場合は、期待値3回くらいなので、設定通りに動いてそうですね。
ほんとは1/2で返していたけど、運良くそれっぽい挙動になった可能性もあるので、サーバーのログを確認してみます。それぞれのリクエストにidというパラメータを割り振ってあります。
それぞれのリクエストが200を返すまでリトライされていることが確認できます。ちなみに、一番左の列はPodの名前です。同じPodにリトライするわけではなく、様々なPodに対してリトライしていることがわかります。Pod固有の問題が起きた際は、リクエストを返し損なうことを防げそうですね。
（そういえばfaultを消し忘れていましたが、RetryとFaultInjectionは同時に設定することはできないようですね。）
Mirroring
HTTP trafficのミラーリングの設定です。オリジナルと同じリクエストが指定した別のServiceにルーティングされるようになります。新バージョンを公開する前に、旧と同じリクエストを流してみて問題ないか確認したり、異常なリクエストを検出ツールに流す等といった使い方が考えられます。あとで説明しますが、Retryの同時進行版という訳ではありません。
という訳でVirtualServiceに設定を入れてみます。
ミラーリングですが、オリジナルと同じ向き先にリクエストを流してみます。オプションでミラーリングを行う割合を変えることができますが、今回はデフォルトの100%で行います。
今回のリクエスト先は先程利用した1:1で200,500が帰るサーバーです。Postmanの結果がこうなりました。
99対101ということで、普通にリクエストした時と変わらない結果になりました。
ログを確認してみます。
同じリクエストが2回発生していて、別のPodに行っていることがわかりますね。
まとめ
istioにはhttpのリダイレクトの機能やリライトなど様々な機能がありますが、見栄えしそうなのを選んで紹介してみました。
次の記事ではOutlierDetection(サーキットブレイカー的な機能)や、Rate Limitなどを書きたいと思います。