ツナワタリマイライフ

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

2019年1Q振り返りと2Q

なんか1Qどうするの表明もしてないしなんか年始に毎週ブログ書くとかいって書いてないしまぁそんなもんだよね。

1月から3月、冬休み明け気合を入れて、というのもあったし、単純にできることが増えた、というのもあったが、いい意味で忙しくできていたと思う。 仕事を通じて技術的に新しいことを学んだり(特にCDNについて学べた)Vimの勉強会にうっかり参加してVim力をあげたり。 あとは会社ブログに少しずつ出していこうと思っているが、Microservicesの受け入れ準備的なものを子issueに分解して少しずつ進めていっている。

2月はフィリピン・マニラに同僚の結婚式ついでに1週間マニラオフィスで働いて「基本的にすべて一発で英語が聞き取れない」という事実を持って返ったりしました。

結局この3ヶ月で何ら具体的に英語学習に関するアクションができていないんですが、いよいよやろうかなと思えたのはSREConのCFPが通ったことですね。 もともと12月から2月ぐらいにかけてオンボーディングに取り組んでいて、一通り済んだ&そういえばグローバルメンバーもなんか興味持ってたってことで 英語でサマリまとめてshareしよう、ついでにSREcon出すだけ出そう!と思ったら通ってしまったという感じです。6月シンガポールです。

www.usenix.org

国内ですら大きいカンファレンスの登壇経験ない(小規模勉強会でのLT程度の経験しかない)のにいきなりマッチョなことしてしまったなぁと思いつつ、まぁ順序なんぞないし、前向きに楽しんでいこうと思っています。 Talkは内容だけで審査するため、個人や会社を特定できる情報は書かないでください、とあったのが、公正でいいなぁと思いました。 LTの募集もOpenしてるみたいなので誰か一緒に行きましょう。

We will accept lightning talk proposals starting on Friday, March 22, 2019

英語の勉強ですが、発音を直してもらいながら学ぶ何かをしたいというのと、Listingの訓練をしたい。で、どうするかって感じですが、 後者に関してはSREconの過去の発表を何度も見て聴くというのをやるつもり。YouTubeの字幕機能でなんとか。英語学習に関しても便利な世の中になりましたね。 発表資料どんなもんかな?っていう勉強もかねて。前者はどうすっかな。そういうていで英会話的なsomethingやるしかないな。

Readingは最近を読んだりもしてるけど、技術学習で英語から学ぶ割合を増やすしかないと思う。さいわい日本語でも学びきれないほど豊富に情報があるけれど、やっぱり新しいこと、これからなこと(特にKubernetes, Microservices, Service meshなんか)は英語のほうが早いし多い。こっちをがっと読んでばっと要点をとってくる筋力をつけたいと思う。

とはいえ、英語に懸念がありつつも、大事なのは中身だと思うので、今回SREで実施した内容に加えて、SREを越えて適用するには、みたいなところもトークに入れ込もうと思っています。 なんか各国のエンジニアチームもオンボーディング重要だと思ってるけどどうしよう?って悩んでるみたいで、「おれの取り組み共有するぜー」って言ったら「うちらも悩んでるのだ!Let's join us!」みたいになってグローバルのオンボーディングyatteiki隊に加入してしまったのでこれを活かしてなんかいい感じにTalkのネタ増やしていきたいと思います。

それと同時に、ちょっと2Qはある程度このTalkと今やってる業務にフォーカスする必要があるなぁと思いました。 ついつい興味が散ってなんでもかんでも手を出しがちな性格なので、意図して時間の使い方を制御しよう、と思ってブログを書こうと思った次第。

登壇や発表より、目の前の課題を解決することが大事なことはわかっていますし、組織のことと同じだけ、技術力が大事なこともわかっています。

それでも僕はOSSや、コミュニティのおかげで今のポジションになれたので、今年はコミュニティ活動もやっていきたいと思っています。

SRE Loungeは運営として携わっていますが、4月はSRE Sessionを企画したり、あと今年中にビックなことができたらいいなぁと画策していたりします。

sre-lounge.connpass.com

技術的には、メタなところではクリーンコード的な視点でちょっと学ばないといけないなぁと思っているのと、 やっぱり作業環境の"速度"(Vim, terminalなど)がまだまだ足りないのでそこは継続的にやっていきたい。 経験が足りないのはどうしてもしょうがないので知識+目の前の問題を解決しながら学ぶってやっていくしかないね。

おしまい。

"失敗から学ぶRDBの正しい歩き方"を読んだ

読んだ。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

知見の宝庫。著者の曽根さんが本書を書く理由を「知見を後の世代につなぐため」といったことをおっしゃっていて(Twitterから見つけきれず。。。)本当にありがたいと思いました。この本自体も様々な参考となる本が紹介されていて、さらに次の学びへつなげることができるようになっています。

本書の中では、「フラグの闇」が印象的でした。これまで削除フラグにより論理削除と呼ばれるものはよく見てきたし、特に違和感を持っていませんでした。しかし、クエリの複雑化(かつ、影響が広範囲に及ぶ)、UNIQUE制約が使えなくなる可能性がある、カーディナリティが低くなる、といった理由があげられており、便利なのはわかる反面デメリットもあることを学びました。

そしてメタな考え方として「DBには事実のみを保存する」(=状態を持たせない)というのが今まで考えていなかった考え方でした。

削除フラグが利用したくなるシーンでも、まず他の方法でできないか検討してからデータベースで状態をもたせるか検討したほうが良さそうですね。

最後に目次をのせて自分の中のINDEXに保存して終えようと思います。

  • 第1章 データベースの迷宮
  • 第2章 失われた事実
  • 第3章 やり過ぎたJOIN
  • 第4章 効かないINDEX
  • 第5章 フラグの闇
  • 第6章 ソートの依存
  • 第7章 隠された状態
  • 第8章 JSONの甘い罠
  • 第9章 強過ぎる制約
  • 第10章 転んだ後のバックアップ
  • 第11章 見られないエラーログ
  • 第12章 監視されないデータベース
  • 第13章 知らないロック
  • 第14章 ロックの功罪
  • 第15章 簡単過ぎる不整合
  • 第16章 キャッシュ中毒
  • 第17章 複雑なクエリ
  • 第18章 ノーチェンジ・コンフィグ
  • 第19章 塩漬けのバージョン
  • 第20章 フレームワーク依存症

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

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

おわりに

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

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