ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

SLO: Service Level Objecive(2) from SRE Workbook Chapter2

blog.chaspy.me

次、Workbookを引っ張ってくる。

余談だが、SREになる前にいろんな(SRE / DevOps / Infrastructure as Codeなどに関係する)本を読み漁っていて、今になっていざ現実の課題に解決する場面になって引っ張り出すというシーンが多くなってきた。とってもいいことだと思う。

ちなみにWorkbookにはSLOに関する章が3つもある。SREのCore Principleなだけある。

  • Chapter 2 - Implementing SLOs
  • Chapter 3 - SLO Engineering Case Studies
  • Chapter 5 - Alerting on SLOs

今回は基本的な実装方針である Chapter2と、それをどう文化的になじませるかのケーススタディを書いたChapter3を流し読みしていく。Chapter 5はMonitoringと組み合わせてのAlertingの話なので、まだ先の話ということでpass。

しかし全章目次とintroとsummeryだけ読んでメモっておいてよかった。

SRE Lounge#6で「The Site Reliability Workbook」について登壇してきました - ツナワタリマイライフ

Chapter 2 - Implementing SLOs

Google - Site Reliability Engineering

. Service level objectives (SLOs) specify a target level for the reliability of your service. Because SLOs are key to making data-driven decisions about reliability, they’re at the core of SRE practices

だいじ

We’ll then cover how to use SLOs to make effective business decisions, and explore some advanced topics.

最終的にはビジネス的な意思決定のためにある。

Our experience has shown that 100% reliability is the wrong target

100%を設定するのは間違っている(reasonableではない)

で、SLIの例をhttpリクエストだとかgrpcだとかであげてくれつつ、最初にSLI/SLOをどう決めて実装したらいいか、といったところで

Your first attempt at an SLI and SLO doesn’t have to be correct; the most important goal is to get something in place and measured, and to set up a feedback loop so you can improve.

に安心感を覚える。

で、はじめるのはシンプル

  • SLOを定義したいアプリケーションを決定する
  • "users"(enduser)を明らかにする
  • そのアプリケーションをユーザはどのように体験するかを考慮する
  • 抽象的なアーキテクチャダイアグラムを作成する。
    • key components, request flow, data flow, critical dependenciesを含む

これ、ちょうどいまProduction Readiness Checklistをやってて、そこでarchitecture diagramを書いてってお願いしていて、「何が含まれてればいいんだ?」って考えてたのとほぼ一致してびっくりした。

ここで架空のシステムを例にSLIの設定方法が説明されてるんだけど、こんなにやんの?!って思ってしまった。

Type of serviceとType of SLIの対応表が以下。ただこれだけネタがあると選びやすい気がする。

Type of service Type of SLI
Request-driven Availability
Request-driven Letency
Request-driven Quality
Pipeline Freshness
Pipeline Correctness
Pipeline Coverage
Storage Durability

(descriptionは本を読んでね)

で、このSLI Specificationから次はSLI implementationにうつる。

まぁ実装に関してはlogなりmonitoringなりでありものを使ってやればいいしどうしても今の仕組みでは計測できないものがあったとき実装を考えるぐらいでいいのかなぁと思う。この本にもengineering workが少なくて済むもんにしなよと言ってる。

でSLOの計算方法とかはまぁそうやねって感じで。

次にSLOのTimewindowの話。例えば月というか30日でやると、週末の数が違ったりするからweeklyがいいよと書いてある。

long(quater)とshort(week)にはそれぞれ利点があって、4weeksぐらいがだいたい一般的にいいんじゃない?ということでした。計測可能なら全部計測したらいいよね。

そして StakehodlerとのSLOの合意。 - Product Manager - Product developer

Once all of these points are agreed upon, the hard part is done.

これができれば大変な部分は終わったようなもので、この合意が将来に渡ってまた難しくなることがあるよ、と言っている。

というわけで、残りは繰り返し改善していくこととadvanced tipsなので流し読み。

おわりに

SLOの導入の仕方がかなり丁寧に書かれていてよかった。SLOやるぞ!どうすれば?ってひとはこの章の前半部分を読むとよろしい。

鍵はどのSLIを設定し、定めたSLOをステークホルダーと合意する、そのプロセスだと思いました。あとはそれだけに終わらない継続的な改善。

エラーバジェットによる開発と信頼性向上のバランスについて合意を取るのが難しそうですが、ひとまず安定しているプロダクトだとSLOの決定と観察からはじめてみてもいいと感じました。

Chapter 3 - SLO Engineering Case Studies

次回!

SLO: Service Level Objecive(1) from SRE 1st book

SLO, SLO, SLO.

言葉の意味は理解しつつも、実際に身をもって使うことができてない言葉だ。そんなこんなでいよいよSLOちゃんとやりますかねと言ったところでSLOってなんだっけってのを深いレベルでちゃんと理解しないとなと思ったので筆を執った次第。

重たい1st SRE bookを引っ張り出してきた。

1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する / Pursuing Maximum Change Velocity Without Violating a Service’s SLO

landing.google.com

  • 信頼性目標は100%であってはならない
  • エラーバジェットを使い切ると新規開発はできない

100%からSLOを引いたものがエラーバジェットである。SLOを下回った場合は、SLOを回復させるための作業に注力する。ただそれだけだ。

エラーバジェットがなぜあるかというと、開発と運用の対立構造が前提にあるように感じる。それを客観的指標で解決しようとしたのがエラーバジェットという考え方だろう。

4. サービスレベル目標 / Service Level Objectives

landing.google.com

結局、SLOというか、SLIをどうやって、それに決めればいいかわからないからもやもやしているのだと気づいた。

4.2.1 サービスの提供者とユーザの関心事

にあるように、すべての指標がSLOになるわけではない。ユーザが何に関心を持っているか。そしてそれによってプロダクトとして何を重要指標とするか。それで決まる。

したがってやっぱりこれはテクニカルに、SREとそのサービスの技術者だけでは決めることができず、プロダクトという単位で決める必要がある。

おわりに

現在、Microservicesを受け入れる基盤ができ、少しずつMicroservicesが生まれ始めている。その中で、テクニカルな(microservices文脈での)サービスに対して、技術的な責任を持つサービスオーナーと、ビジネス的な責任を持つプロダクトオーナーを定めようとしている。(プロダクトオーナーはプロダクトマネージャという言葉でのプロダクトという言葉があるし、言葉の定義はまた変わると思うけど、とにかくmicroservices文脈/単位での技術的責任と、それらを包含し利用するプロダクト/ビジネス責任を定める必要があるが、現状様々な歪があるという状況だ。)

SLOは、この後者のビジネス的責任を負う組織が決まらないと、決めることができない気がする。

Production Readiness ChecklistでStakeholderを決め、Service Owner / Business・Product Owner / SRE とでSLI ・SLOを合意、その共通認識を持って進めていこうね。この基準だけは守るようにみんなでうまいことやっていこうね。そういうのが目指す姿な気がしている。

SREのjob descriptionを眺めてみる(国内編)

海外編があるのかは知らない。

はじめに

最近job descriptionを見直す機会があったので、他社はどうなんだろうとふと思いついたので眺めてみる。

さて企業をどうチョイスするかという問題がある。SREのカンファレンスは国内にはないので、お世話になっているSRE Loungeに登壇されてる企業さんを見てみようと思います。

Indeed

なんか2つあったので新しいっぽい番号のほうをみてみる。

Systems Engineer, Site Reliability Engineering (SRE) / サイト信頼性エンジニア - External Careers

ミッション、サービス規模が書いてあっていいですね。あと24/365対応できるよう、いろんなタイムゾーンにSREがいるようでいいですね。Responsibilitiesもせやなって感じ。

Minimum Qualificationsはあまり厳しくしぼっていなくて、CSの学士か相当のもの、Coding Skill、Linux/Unix OSの経験。

Preferred Qualificationsもまぁせやなって感じで、あまり厳しい感じにはなっていないようでした。

ランサーズ

募集してないようでした!足りているというのはいいことですね。

スタディプラス

教育系ITでトップクラスのトラフィックを支える一人目のSREエンジニアを募集! / スタディプラス株式会社

1人目🤔

業務内容はわりとしっかり書かれていいですね。stackshareにリンク貼られてる点も。

インフラはAWSとだけしか書かれてないので、AWSで使ってるサービスや、アプリケーションがどこでどう動いているかもかかれてるとなお良いですね。

オプト

募集なし!よいことですね!

ヌーラボ

募集枠・JDは公開されてないようでした。エンジニアは積極募集してるわけじゃないのかな。

ヌーラバーになりませんか? | ヌーラボ

Wantedly

コーポレートサイトからはたどりつけず。WantedlyなのでWantedlyにのってるかなと思ったらのってました。

インフラエンジニアという名前ですがこれでしょう。

そろそろ就活?まずはインターンで会社の中身を知りたいインフラエンジニアへ - Wantedly, Inc.のインフラエンジニア新卒・インターンシップの求人 - Wantedly

3つの軸いいですね。

- ビジネスの変化や、技術の変化を受け入れるインフラ 
- エンジニアの生産性を上げるインフラ(開発基盤) 
- 堅牢なインフラ

Kubernetes / Istio と使用しているソフトウェアがちゃんと乗っているのも良いです。

あ、これインターンですね。

Wantedly, Inc.の会社情報 - Wantedly からはSREにたどり着けませんでした。募集してないのかな。

Folio

コーポレートサイトからこちらに飛べました。

大規模なFinTechサービスを支えるSRE募集! - 株式会社FOLIOのインフラエンジニア中途の求人 - Wantedly

我々はMicroserviceとマルチクラウドの世界を描いています。

と重点をおいているテーマがのっていていいですね。

必須・歓迎条件とともに、かなり具体的な使用技術が書かれてあるのもわかりやすくていいです。

freee

freee k.k. Careers - SREエンジニア:eng

【取り組んでいただく課題の例】 がきっちり書いてあって応募者のやる気を駆り立てそうでいいですね。

応募資格の 複雑なWebアプリケーションの開発・運用経験 、複雑なWebアプリケーションってどこからだろう?と気になりました。

ソフトスキルというか、性格面に言及しているのはマッチングを高めそうです。

【下記どれかにピンと来る人歓迎】
・面倒なことは全部自動的にやってもらいたいと思う 
・前例にとらわれず、本質的な価値を追求したい 
・常に新しいことに挑戦していたい 

メルカリ

Mercari, inc. - Jobs: Software Engineer, Site Reliability - Apply online

必須条件が実際の業務に結びついていそうで、簡潔かつ最小限で良いと思います。

メルカリさんはMicroservice Platformとチームが別なんですよね。そこが他にはないので説明があるとなおよさそう。

Gunosy

Backend System/Site Reliability エンジニア(BSE/SRE) | 株式会社Gunosy

Indeedと同じくCS学士が必須に載っていますね。他の必須条件も、クラウド・Infrastructure as Code・パフォーマンスとSREで必要な素養が網羅されていていいですね。

Gunosy事業への共感

をあえてあげているのも他ではみなかった点ですね。

Speee

【デジタルトランスフォーメーション】SREエンジニア / 株式会社Speee

必須・歓迎ともにゆるめに書かれてますね。そのかわり使用技術が細かく書かれているので良いですね。

おわりに

だいたい同じようなこと書いてるなあと思いつつ、会社によって微妙な差異があって面白いですね。個人的には公式のJDが決め手になることは少ないにしても、「応募してみようかな!」って気持ちにさせるには、挑戦できる課題や、細かい使用技術、大事にしている文化等あるとなお良いと思いました。

QuipperではSenior SREを募集しています。

Quipper Japan | 採用情報 | 募集要項

AWSのRegion Code(ap-northeast-1とか)をシュっと出すコマンドawsrc

はじめに

記憶力低下に伴い覚えきれないしもう何十回ググったかわからんのでカッとなって作った。

github.com

まぁ全然gistで十分だった。bashです。みんなだいすきpecoです。

gif動画

なんやかんやこういうの作ったことなかったのでttyrecとttygifで作った。

しかしなぜかこうチープになるな。。。

kakakakakku.hatenablog.com

参考

おわりに

本当記憶力の低下がやばい。

「入門監視」の翻訳レビューに参加した

はじめに

でましたね。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

本当に良い本です。「監視とはなんぞや」からはじまり、「監視はこうやるな」「監視はこうやれ」という思想が最初の3章までに詰まってます。最初の3章までは開発者すべてのひとが読んだらいいんじゃないかな。それ以降は必要なところをおのおのがつまみ食いしていけばいいと思う。SREになる前に読みたかった本です。(原著は出てたわけだけどね)

本自体の解説はいろんなひとがレビューしてそう(出遅れた!)のでそちらを!翻訳者の松浦さん、付録を執筆されたsongmuさんの記事含めてご紹介。

どうして翻訳レビューをしたのか

翻訳コミュニティyakstで募集がかかったので、読みたい本でもあったし、いい機会だったので参加しました。9月ぐらいだったかな。(なお入りつつもまだ1つも翻訳投稿していない。。。)

yakst.com

英語(原著・一次ソース)を読めというのはごもっともだし、自分もそうしていますが、かといってじゃあ技術書全部英語で読んできたのかっていうともちろんそうでもないし、数多くの翻訳書のおかげでエンジニアとしてスキルアップできたのも事実です。

「教育」に興味があってQuipperで働いているけれど、教育に関連して、そういう底上げができる・広く広げることができる、その両方の特性を持った翻訳という範囲にはずっと昔から興味がありました。コミュニティのリーダーであり、「入門Kubernetes」「SQLパフォーマンス詳解」の訳者である松浦さんはデブサミGitHubのサポートエンジニアとしての発表をしているのを見て知って、魅力的な仕事だなぁと思ったのを覚えています。

入門 Kubernetes

入門 Kubernetes

SQLパフォーマンス詳解

SQLパフォーマンス詳解

翻訳レビューどうだったか

訳者あとがきで名前を載せていただいたのですが、最初の(訳された)原文に比べるとかなり読みやすい日本語になったと思いますし、貢献はできたという自負があります。実際、(おそらく)オライリーの編集者の手が入ったあとの完成版を献本いただき、一通り読み直しましたが違和感なかったです。

ざっとレビューした数を数えたら76個でした。もちろんコメントだけのものもありますし、別の案が採用されたものもあります。あとは意識的に一番にレビューするようにして、なるべく多くの貢献ができるようにしました。数がすべてではありませんが、自分の経験として良いものになりました。

「その文に違和感のある理由」「代替案」「+コメント」という形式でレビューを行いました。実際、日本語を読んで原文も読んでからコメントをするのですが、「正しく訳すこと」と「日本語として読みやすいこと」はまったく別物であることをあらためて実感しました。英語の訳としては正しいけどこの日本語はちょっと、という例がなかなかあり、翻訳の難しいところだなぁと思いました。レビューですら難しかったので、実際に訳すのはもっと難しいですよね。

おわりに

これまで国内になかったタイプの本が翻訳という形で世に出版される瞬間に立ち会えて本当に嬉しいです。

翻訳、興味あるあるいいながら実際にできてないので今年こそは地道に、小さな記事からでもやっていって、貢献していきたいと思います。

2019年

2018年の目標は全然守れてなかったなー。

転職してバタバタのままバタバタだったって感じです。

冬休みちゃんと休んだので2019年はちゃんと生きるようにします。

Engineering

SREとしてもっと「いい感じ」に。学習は英語主体に、スピードが落ちないように、本質をつかむようにやっていく。オライリーSafariをちゃんと元とったって言えるように使う。

幸い、日頃の運用業務、他チームからの依頼に加えて、中・長期的な改善、ビッグプロジェクトとやりがいのあるチームにいる。一通りなんでもSREの仕事ができるようになった上で、自分がリードしての改善も月に1つ以上はできるようになる。

今足りてないのは、日常のひとつひとつの動作の効率化なので、それは継続的にメンテナンスする。大きめな/新しめなことを学ぶときは登壇と合わせてアウトプット駆動にする。本を読んで終わりにしなくてちゃんと手を動かすか、まわりに伝える、という学習法にしたい。

English

今年一番力をいれたい。TOEICを目標にするつもりはないので、定量的な力が出しづらいところ。

とりあえず直近は2月にフィリピンに行くので、最低限の英会話ができるようになること。あとは仕事上の読み書きを調べずに大意を読めるようになること。(特に書きがまだ検索しながらで、チャットでのレスポンスが遅れがち)。海外カンファレンスのキーノートスピーチの英語ぐらいは理解できるようになること。

英語でのプレゼンテーションもやれるようにしたい。

Health

転職してさらに無限に太ったのでなんとかします。3月までにマイナス10kg、以降維持。体脂肪率は13%ぐらい、をいったん適当に目指す。

朝型にして寝酒をやめてジョギングと筋トレを習慣化する。ついでに英語学習と合わせたい。podcastがいいかいな。シャドウイングできる何かとか。

Apple Watchでの活動量リングを毎日つなげるようにする。

Money

マネーフォワード&電子決済で可視化したはいいけどほったらかしでまったく意味をなしてない感じになっていました。

これも週2チェックで習慣化。あと5月頃引っ越したいので5月までに50万溜める。以降も消費ペース、範囲をちゃんと知って、知った上で使うようにする。あんまり年いくら貯金、とかはしたくないけど、いつ指が10本折れて失業してもいいように100万は貯めてみたい。

Hobby

英語学習のついでだけど、趣味としても海外ドラマ、映画を見ていきたい。Netflix契約した。

次に登山。2年ぐらい前から仲間誘ってやってたんだけど、どうも日程合わせるの難しかったりするので、今年からは単独登山で、月に1度は行く。まずは日帰りから。PCを持たない日を作るのも大事な気がするし。持っていくかもしれないけど。

音楽も変わらず。継続してこれまでと同じペースでやる。

Other

他、(技術)翻訳に興味がある、まずは短い記事から少しずつやっていく。現在進行系で進化中のものの翻訳はやはり難しい。まずは単発の記事、次に更新がかからないようなまとまったドキュメント、といった風にやっていきたい。

旅行。20代のうちに47都道府県行く、という夢がついに叶ってしまった。海外旅行に年に2、3回は行きたいところ。ここ最近よく帰省してたので、しばらくやめて、長期休暇は海外に出ようかな。さすがに全世界制覇は言えない、が、英語学習効果を試すのもかねて、まずは英語圏/英語が通じる国にたくさん行きたい。

目標とか振り返りとか

あと去年やってたQuoter/Mionthlyの目標、振り返り、途中で死んでしまった。月ごとというのもやっぱりスパンが長い。

数値の簡単な振り返りとして毎週ブログを書いていこうと思います。指針確認と振り返りを短いスパンでやることで習慣が消えないようにするため。

おわりに

まぁ本当は各分野それぞれゴールが何でそのために何をやっていくとか細かく書いたほうがいいんだけどそれはあとでScrapboxかなんかにまとめようかなあ。

ざっくり言うと「ちゃんと・確実に・しっかり」やって力つけていくぞーって感じの1年にしたいです。よろしくおねがいします。

Try "Istio on GKE"(1)公式ドキュメント編

はじめに

App Meshも発表されたのでService Meshちゃんと動かしておこう、って感じです。

で、App Meshではなくさくっと動かせそうなGKE(慣れてる)で、親和性も高そうなIstioを試すことにします。

Istio on GKE

Setup

Istio on GKE  |  Istio on GKE  |  Google Cloud

GKEでクラスタ作成するときのオプションでIstioをデプロイすることができます。とはいっても、Istio自体のdeployはkubectl applyでできるのでそれ自体はあんまり嬉しくないけど、自動でvupとかしてくれるみたいだ。

Istio on GKE lets you easily manage the installation and upgrade of Istio as part of the GKE cluster lifecycle, automatically upgrading your system to the most recent GKE-supported version of Istio with optimal control plane settings for most needs.

Kubernetesのバージョンは1.10.9、現在のデフォルト。これ以降じゃないとあとででてくるenvoy proxyのauto injectionができないらしい。

$ gcloud container clusters list
NAME          LOCATION           MASTER_VERSION  MASTER_IP     MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
istio-on-gke  asia-northeast1-a  1.10.9-gke.5    35.200.74.23  n1-standard-1  1.10.9-gke.5  5          RUNNING
$ kubectl get service -n istio-system
NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                                                                                                                   AGE
istio-citadel              ClusterIP      10.35.243.80    <none>           8060/TCP,9093/TCP                                                                                                         4d
istio-egressgateway        ClusterIP      10.35.250.97    <none>           80/TCP,443/TCP                                                                                                            4d
istio-galley               ClusterIP      10.35.255.181   <none>           443/TCP,9093/TCP                                                                                                          4d
istio-ingressgateway       LoadBalancer   10.35.247.113   35.200.104.141   80:31380/TCP,443:31390/TCP,31400:31400/TCP,15011:32105/TCP,8060:30651/TCP,853:30293/TCP,15030:31022/TCP,15031:31609/TCP   4d
istio-pilot                ClusterIP      10.35.249.186   <none>           15010/TCP,15011/TCP,8080/TCP,9093/TCP                                                                                     4d
istio-policy               ClusterIP      10.35.254.135   <none>           9091/TCP,15004/TCP,9093/TCP                                                                                               4d
istio-sidecar-injector     ClusterIP      10.35.255.211   <none>           443/TCP                                                                                                                   4d
istio-statsd-prom-bridge   ClusterIP      10.35.253.65    <none>           9102/TCP,9125/UDP                                                                                                         4d
istio-telemetry            ClusterIP      10.35.242.127   <none>           9091/TCP,15004/TCP,9093/TCP,42422/TCP                                                                                     4d
prometheus                 ClusterIP      10.35.250.123   <none>           9090/TCP                                                                                                                  4d

grafanaがいないのが気になりつつ、、、

Enabling sidecar injection

これが最高便利だなぁと思っていて、namespaceにこのlabelをつけると、applicationをdeployしたときに自動的にsidecar proxyが注入されます。applicationのyamlに手をいれなくていいというのがいいですね。もちろんistioctlでyamlに手を入れることもできます。

$ kubectl label namespace default istio-injection=enabled

既にbookinfoのsampleをdeploy済なんですが、podを見てみるとちゃんとsidecar proxyもいることがわかります。

$ kb describe po productpage-v1-f8c8fb8-httpw
(snip)
Containers:
  productpage:
    Container ID:   docker://8d322f8e56735d7b02899fe79a900f7b62ea12fd3be7314c1e9fc0a8d900570f
    Image:          istio/examples-bookinfo-productpage-v1:1.8.0
    Image ID:       docker-pullable://istio/examples-bookinfo-productpage-v1@sha256:ed65a39f8b3ec5a7c7973c8e0861b89465998a0617bc0d0c76ce0a97080694a9
    Port:           9080/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 18 Dec 2018 19:35:20 +0900
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:        100m
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-q4s8k (ro)
  istio-proxy:
    Container ID:  docker://e882a24ce250b65281b16200ddca51153d888e6e918b2e0ab8d3eefeb1f58418
    Image:         gcr.io/gke-release/istio/proxyv2:1.0.2-gke.0
    Image ID:      docker-pullable://gcr.io/gke-release/istio/proxyv2@sha256:826ef4469e4f1d4cabd0dc846f9b7de6507b54f5f0d0171430fcd3fb6f5132dc
    Port:          <none>
    Host Port:     <none>
    Args:
      proxy
      sidecar
      --configPath
      /etc/istio/proxy
      --binaryPath
      /usr/local/bin/envoy
      --serviceCluster
      productpage
      --drainDuration
      45s
      --parentShutdownDuration
      1m0s
      --discoveryAddress
      istio-pilot.istio-system:15007
      --discoveryRefreshDelay
      1s
      --zipkinAddress
      zipkin.istio-system:9411
      --connectTimeout
      10s
      --statsdUdpAddress
      istio-statsd-prom-bridge.istio-system:9125
      --proxyAdminPort
      15000
      --controlPlaneAuthPolicy
      NONE
(snip)

productpage containerの他にistio-proxy containerがいる。

istioctlでinjectionしたときのdiffはこんな感じ。

gist.github.com

Enabling Stackdriver tracing and logging

Service MeshといえばObservability。デフォルトでStackDriver logingとtracingと連携できるようですね。

https://storage.googleapis.com/gke-release/istio/release/1.0.3-gke.0/stackdriver/stackdriver-tracing.yaml

このyamlをapplyします。

$ kubectl apply -f stackdriver-tracing.yaml
stackdriver.config.istio.io "tracing-handler" created
tracespan.config.istio.io "stackdriver-span" created
rule.config.istio.io "stackdriver-tracing-rule" created

stackdriver, tracespan, rule というkindが追加されます。tracingの設定もyamlで定義できるのはいいですね。

loggingも同様にapplyしていきます。

https://storage.googleapis.com/gke-release/istio/release/1.0.3-gke.0/stackdriver/stackdriver-logs.yaml

stackdriver, logentry, rule というkindが追加されます。

$ kubectl apply -f stackdriver-logs.yaml
stackdriver.config.istio.io "log-handler" created
logentry.config.istio.io "server-accesslog-stackdriver" created
logentry.config.istio.io "server-tcp-accesslog-stackdriver" created
rule.config.istio.io "stackdriver-log" created
rule.config.istio.io "stackdriver-log-tcp" created

logging, tracingともに有効になったようです。bookinfoアプリをなんとなしリロードするとなんとなし結果が見えます。さて、Googleのドキュメントはここで終わりなので、次はIstioそのものについて見ていきます。

Istio

Istioの核となる機能であるTraffic Managementを見てみましょう。

Istio / Traffic Management

あらたなリソースが追加されています。rule configurationを見ていきます。

Istio / Traffic Management

There are four traffic management configuration resources in Istio: VirtualService, DestinationRule, ServiceEntry, and Gateway:

追加されたリソース

  • VirtualService

    defines the rules that control how requests for a service are routed within an Istio service mesh.

どのようにServiceにroutingするかの設定のようです。見てみましょう。

$ kubectl describe VirtualService bookinfo
Name:         bookinfo
(snip)
API Version:  networking.istio.io/v1alpha3
Kind:         VirtualService
(snip)
Spec:
  Gateways:
    bookinfo-gateway
  Hosts:
    *
  Http:
    Match:
      Uri:
        Exact:  /productpage
      Uri:
        Exact:  /login
      Uri:
        Exact:  /logout
      Uri:
        Prefix:  /api/v1/products
    Route:
      Destination:
        Host:  productpage
        Port:
          Number:  9080
Events:            <none>

GateWayを指定して、そのgatewayからうけたリクエストを見て、pathがmatchしたら流す先はこれ、というものみたいですね。

  • DestinationRule

    configures the set of policies to be applied to a request after VirtualService routing has occurred.

VirtualServiceで受けたあとDestinationへ流すためのRuleSetっぽいですね。見てみましょう。

bookinfoのapplicationにはなかったので、istio-system namespaceにあったものを見てみます。

$ kb describe DestinationRule istio-policy
Name:         istio-policy
Namespace:    istio-system
Labels:       addonmanager.kubernetes.io/mode=Reconcile
              k8s-app=istio
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"networking.istio.io/v1alpha3","kind":"DestinationRule","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconci...
API Version:  networking.istio.io/v1alpha3
Kind:         DestinationRule
(snip)
Spec:
  Host:  istio-policy.istio-system.svc.cluster.local
  Traffic Policy:
    Connection Pool:
      Http:
        Http 2 Max Requests:          10000
        Max Requests Per Connection:  10000
Events:                               <none>

trrafic policy -> connection pool -> http とほって、max requestのような設定を定義してるようですね。

  • ServiceEntry

    is commonly used to enable requests to services outside of an Istio service mesh.

Istioの外のサービスへのリクエストを許可するためのもの。

これはbookinfoをapplyした時点では存在しなかったのであとで解説を読むとします。

  • Gateway

    configures a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the mesh to enable ingress traffic for an application.

applicationが一番最初にトラフィックをうけるLoad Balancerの設定。

$ kb describe gateway bookinfo-gateway
(snip)
Kind:         Gateway
(snip)
Spec:
  Selector:
    Istio:  ingressgateway
  Servers:
    Hosts:
      *
    Port:
      Name:      http
      Number:    80
      Protocol:  HTTP
Events:          <none>

さて、ドキュメントではさらに詳細にひとつひとつのリソースについて説明されているのでそこを見ていきます。

VirtualService

  • Virtual Serviceはrequestを流すdestinationを複数定義でき、weightによって割合を決めることができる
  • timeoutやretryも設定できる。timeoutのdefaultは15sec
  • fault injectionもできる。何%の割合で、遅延を何秒間発生させたり、httpで400を返すさせたりできる
  • requestを受けるsourceをlabelで限定できる
  • rule/conditionは上のものが優先して適用されます。これは重要です。

DestinationRule

  • VirtualServiceのあとに適用されるrule
  • maxConnectionsを100とかに設定してそれを越えたら接続を切るcircuit breakerの設定ができる
  • rule適用はVirtualService、DestinationRuleのhost、subsetの順で適用されるかどうかが検討される

ServiceEntry

  • 外部サービスと接続するためのentry(そのまんま)

Gateway

おわりに

つかれたので一旦ここで終わります。次はBookinfoを動かしたり、Traffic Management設定を実際に変えてみたりしようと思います。

参考