3日目（最終日）のメモです。各セッションを振り返ったあと、総括をします。
How We Used Kafka to Scale Database Infrastructure
LinkedIn内部で使われているドキュメントデータベースであるEspressoについて、Kafkaを使ってデータのレプリケーションをどう行っているかを解説したセッション。
EspressoはバックエンドにMySQLを用いたクラスターデータベースで、以前はデータの可用性を高めるためのレプリケーションをMySQLのレプリケーション機能を用いて行っていた。ただそうするとインスタンス（ノード）ごとのレプリケーションとなり、柔軟性やフェイルオーバー時の負荷の集中などに課題があったので、Kafkaを使ってパーティション単位のレプリケーションにアーキテクチャを変更した、というのがセッションの主旨。
Kafkaを用いて工夫しているのは、次の3点がポイント。
- KafkaのメッセージにはGTID(Global Transaction Identifier)が振られていて、必ずその順番でスレーブに適用されるようになっていること
- マスターのフェイルオーバー時には、スレーブ自らがメッセージをプロデュースして、新しい世代番号のGTIDを発行して、それを自分自身がコンシュームすることで、マスターの切り替えを厳格に行えること
- メッセージのチェックポイントの機構を持っていて、あるメッセージがパブリッシュに失敗しても、直前のチェックポイントからやり直す仕組みがあること
他のカンファレンスやウェブの記事でもいくつか取り上げられていて、例えば下記のスライドが詳しいのでこちらを見てもよいと思う。内容は9割がた同じ。
www.slideshare.net
How to Start On-Boarding of SRE
Quipperに勤務する日本人の @chaspy_ のセッション。オンボーディング(入社またはチームにジョイン後、仕事にスムーズに入っていくための講習・手続き・サポートなど)に焦点をあて、SREのオンボーディングはどうあるべきか、Quipperでの実例が語られた。
自身がチームにジョインした際、完全に1人で動けるようになるには半年かかった経験から、オンボーディングを適切に行うことでこの期間を短縮できるのではと考え、自らが新入のメンバーに対してオンボーディングを企画して始めた。
技術面とメンタル面の2つに注目して、前職の仕事内容とのギャップ、それにともなう精神的不安があったとし、それを解消するようなオンボーディングを実施することで、新しいメンバーは2ヶ月で自立できるようになったとのこと。
オンボーディングにおけるポイントは3つ。
(1)ゴールを設定すること。
- チームのミッションは何か？
- チームは何の責務を負っているか？
- 日々やらなけれればならないことは何か？
ここから何をできるようになればよいのかが定義できる。Quipperの場合は「Infrastrucure as Codeが実践できる」「アラートに対応できる」「Pull Requestがレビューできる」「中長期タスクに取り組める」がある。
これをもとに、(2) 学習曲線をデザインしていく。
セッション内では、GitHubのIssue、Pull Request、Quipperのウェブ上のHandbookなどを用いてハンズオンでオンボーディングが進められている様子が紹介された。
(3) 1on1を通じてフォローすること
1on1では「直近やっていること」「次週の計画」「いま困っていること」をフォローする。そして、最初に定義したゴールへの進捗を追いながら、自立までフォローしていく。
これらは今ではテンプレート化され、社内の他の部署でも使われるようになっているとのことだった。
オンボーディングをここまで体系立ててやっている事例紹介はあまりないので貴重だった。
発表資料はこちら。
Lightning Talks
5分ずつだが、短いなりにコンパクトにまとめられていてテンポがよく、どれも良かった。
Developing Effective Project Plans For SRE Internships
SREのインターンをどのようにやるべきか？を考察。
- 「実験的なもの」または「まだ未着手な(Greenfield)もの」に取り組んでもらう
- 何かをship(本番リリース)してもらうことを重視しよう
- 運用業務とコードを書くことを両方入れよう。SREの実際の業務イメージを体験してもらう
- メンターの自分自身でもやりたいタスクかどうか？を考えよう
- インターンのアウトプットに対する期待値の最大・最小をイメージとしてもっておこう
Zero Downtime Cross-Cluster Migration of Microservices in Kubernetes
Kubernetesのクラスター間でマイグレーション（移行）する際にゼロダウンタイムで行った事例紹介。
クラスターはVPNで相互接続されていて、両者のPod間での疎通ができることを前提として、Migration Controller（おそらく自作）が両クラスタにいて、LabelとAnnotateをうまく使ってトラフィックをスイッチしているようだった。LTだったこともあり詳細はわからず。
How to Ruin an SRE-Dev Relationship in 3 Simple Steps
SREと開発チーム（dev）の関係をどうあるべきか、どうしたら両者の関係が壊れてしまうのかという逆説的な視点から考察。
- [step0] 相互理解すること
- SREのResponsibilityを定義する
- SREとdevはアプローチは違えどゴールは同じことを確認する
- [step1] 相互に信頼すること
- ミーティングで話し合う
- devが本番環境で辛いと感じていることを聞き出し、改善する
- [step2] コラボレーションする
- 定義ミーティングを設ける
- 次の四半期でやることを一緒に計画・実践する
An Effective Agile SRE Workflow
SREはたくさんやることがある。ワークフローを最適化したいよねということで、うまいやり方の提案。
- 「SREのメインプロジェクト」「リクエストに対する対応(Toil)」の2つのボード（Kanbanをイメージしていると思われる）に分けて管理
- WIPの数を制限
- Interrapt Shieldを使おう（今はこのタスクに着手できないって自らストップかけることを宣言するようなイメージに感じた）
5 Actions for Training Your SRE Team
SREチームとして成長するための5ステップ。
- 学習するための安全な場所を持とう
- システムリソース的な話なのか、場所の話なのか、心理的安全のことなのか、ちょっと聞き取れなかった
- チームの他のSREのことを知ろう
- その際、彼らの評価という視点からは切り離して捉えることが重要
- 技術的にどこにフォーカスするかを決めよう
- ワークグループを作って皆で一緒に取り組もう
- 進捗をトラッキングしてチーム内で各自共有しよう
Managing Terraform State at Stack Overflow
Terraformのアップグレードの話。おそらくモジュールのアップグレードに焦点をあてた話。アップグレード時にStatefileに差分が出たり壊れたりするケースがあるようだが、Terraformのアップグレード自体はまだ経験がなくピンと来なかった。
Transparency—How Much Is Too Much?
透明性の重要性について、いくつかのフェーズに分けて考察。
- エンジニアチーム内での内部の透明性
- 組織内・社内での内部の透明性
- 社外のステークホルダーとも情報を共有する透明性
- 全世界にパブリックに情報を公開するという意味での透明性
Dashboards for Thousands of Services
Googleでダッシュボードをどう作っているかという話だと思うが、ポイントがいまいちわからず。
- アプリケーションの SLO→メトリクス→アラート→ダッシュボード、とする
- 標準化する、水平にデータを集める、サービスオーナーが自身でダッシュボードを作れる
What SREs Can Learn from Moms about the Preventative Paradigm
母の育児という仕事は「予防、事前に対処する」という行動ばかりでSREにとって大変参考になるという話。言われてみればそう感じることも多く、LTの中で一番おもしろかった。
SREの職務全般と母の仕事にも共通点が多い。
Our Practices of Delegating Ownership in Microservices World
メルカリで組織をスケールさせるという視点で、マイクロサービスを管理権限をどのように各マイクロサービスチームに権限移譲しているかという話。
ポイントとしては
- Terraformの設定ファイルはモノレポで管理
- 本番環境チェックリスト、GitHubでチェック＆レビューのプロセスを回している
Error Budgets in Banks—Challenges & Way Forward
Error BudgetをBank社でどのように運用しているかについて。エラーバジェットに透明性を確保することで、実際の金銭の予算のアロケーションとも連動させているというような話だと理解。
Aperture: A Non-Cooperative, Client-Side Load Balancing Algorithm
TwitterのFinagleの内部で使われているロードバランサのApertureのバランシングアルゴリズムについてのセッション。
Client-Sideというのでこれは最初ブラウザのJavascriptで制御する話かと一瞬思ったがそうではなく、Finagleのマイクロサービスのクライアントという意味(Finagleは主にScalaで実装されている)。
話は下記の記事と共通する部分が多い。使っている図も同じ。
Aperture Load Balancers — Finagle 19.5.1 documentation
横に並列に大量にスケールさせたサーバー同士で通信する場合の接続先について考えたときに、各サーバーが相手先の全サーバーに全部均等にコネクションを貼ろうとしてしまうとコネクション数が爆増してしまう。そのため、例えば相手の接続先が100台あったとしても各サーバーが実際につなぐのはそのうちから選んだ3つに対して接続させるようにして、それがうまく均等にできればリソース効率が良い状態にできる。その際に考慮に入れるのは接続先に対するレイテンシと、接続先の負荷状態。
セッションでは、どのようなアルゴリズムを試してきたかを紹介し、 現在たどりついたベストの実装について述べていた。
自分の理解では、図のようなリング（輪）のトポロジで、各サーバーをリング状に均等に割り振り、それを接続元・接続先を一緒の円として重ねたときに重なる部分がそれぞれの接続元が接続先につなげるときのサブセットとして決まる。
それを一回決めるだけならそれほど難しくないが、次のチャレンジはそれを継続的に行うことだ。サーバーは数が増減するしトラフィック量も負荷状況も変化していく。各サーバーが次のリクエストで接続先を選ぶときに中央で管理するのではなく個別に（discrete）判断して、それがうまく推移的になり、結果的にランダムに配分されている、それがResiliencyといえる。そうしたアルゴリズムの詳細についての解説だった。
High Availability Solution for Large Scale Database Systems
Baiduのエンジニアによる、超大規模のMySQL運用において高可用性を保障するための工夫について述べたセッション。
BaiduにおけるMySQL利用の規模はかなりのもので、1万ノード以上、ペタバイトのデータ量、複数のクラウド利用およびハイブリッド、MySQLバージョンの混在など、運用が大変なため、自動化の必要性に迫られていた。
これだけあると故障は日常的にあるので、HA構成をきちんと取らないといけないが、Baiduでは決済取引などのクリティカルな用途にもMySQLを使っているので、ノードのFail検知や復旧後のデータの一貫性については譲れない要件だった。さらに規模の大きさから同時並行で処理ができる必要があり、既存のソリューションであるMHAやMMMではその要件を満たせなかったとのことだった。
Baiduで採用したアプローチはXAgentというプロセスをすべてのMySQLノードに配置して管理するというもの。設定を注入するノードは別途いるが、XAgentはそれぞれ個別に協調動作し、SPOFは無い。
さらに、ノードのFailを検知する仕組みについても解説があった。「ノードがFailした」と一言でいってもさまざまな状況があり、一時的に負荷が高くて応答しないだけかもしれないし、ネットワークのレイテンシが高いだけかもしれないなど、ミス検知してしまう可能性はいくつものケースが想定される。そこでBaiduでは3レイヤーに分けて検知のアルゴリズムを組み、ミスがないようにしているとのことだった。
次に、フェイルオーバーの際にデータの一貫性をどう厳密に保障するかという話があった。
フェイルオーバーといってもレプリーションのやりかたがasyncなのか、semi-async（Group Replication）なのか、Raft/MGR(これがなぜここで出てくるのかわからなかった)によって異なるとし、細かい調整をやっている話だったが、この詳細は理解ができなかった。
Ironies of Automation: A Comedy in Three Parts
自動化の皮肉、ということで、自動化によって生じる新たな問題と、それに対して人間と機械のバランスをどうとるべきかについて述べたセッション。
"Ironies of Automation"というのは、約30年前の1983年にBainbridgeによって書かれた文書とのことだ。私は知らなかったので軽く読んでみた。
Ironies of Automation
（自分なりの要約）機械による自動化は、自動化した際には想定していなかった事態が起こったときにオペレータが臨機応変に対応できる能力が落ちてしまうことにより、新たな問題を生む。時間をかけて蓄積したオペレータのCognitive Skillは非常に価値があり、高度な自動化がなされたシステムであっても経験を積んだオペレータの価値は変わらない。
この文章には2012年にBaxterらによるフォローの文書がある。
The ironies of automation … still going strong at 30?
(自分なりの要約)Bainbridgeが言及したときから30年たったが、原則は変わっていない。むしろCloudComputingの登場などで新たな問題が生まれている。
おそらくこれらを前提としたうえで、3つの仮想のエピソードが紹介される。
ただ、これが寓話にSREのケースを当てはめて話を進める感じで、いまいちよくわからなかった。
1回聞き直してみたがそれでもわからない。英語がわからないのはもちろんあるが、前提としているコンテクストの知識が足りないのだと感じる。
部分部分で何を言っているかは分かる。このセッションはクロージング・セッションであって聴衆に考えさせるのが目的でプレゼンターも断片的に問いを投げかけている構成になっているから一貫したストーリーというかポイントがあるわけではないのかもしれない。ただそうだとしても、自分の中で飲み込めるまでには理解できないのが悔しい。
とりあえずメモだけ。
- 監視を誰が監視するのか？
- 中長期に運用していくうえで身につく知識は、使わなければ失われてしまう
- 遭遇したことのない未知の事象にどう対処するかを教えることはできるのか？
- 過去の障害レポートから学ぼう。Postmortemsは書いて終わりではもったいない
- システムはあなたが思っているようには動かない。システムを「再発見」しよう
- あなたはどうしていくのか？自分の冒険を選ぼう。これまで何を経験してきただろうか？
- 機械学習は自動化を一歩推し進める。自動化することを自動で生成できる。
- Second Order Effects（二次効果、副次的効果）
Ethics in SRE (Virtuous SRE)
「SREの倫理」(プレゼン資料でのタイトルは「徳の高いSRE」)と題して、SREが持つべき倫理観について述べたセッション。決して「こう考えるべき」「こうすべき」をいうセッションではないので各自のコンパスを持ってもらいたい、とことわりを入れながらも、倫理観をもって行動していこうと諭すセッションだった。
前提知識として、ACM code of ethicsという文書があるらしい。
Code of Ethics
このセッションも概念的で理解がとても難しかった。全体としていいたいことは分かる。SREとして社会的責任を帯びていることを自覚して自分なりの価値観をもって高潔に行動していこう、ということだ。
ただ、途中の、
- Deontologism 非存在論？
- Consequentialism 結果論？
- カントのCategorical Imperativ 定言的命法？
このあたりの単語が？？？で中間はほとんどわからなかった。日本語に訳してもよくわかっていない。このへんの知識をある種の教養として持っていることが半ば期待されているようで悔しかった。
最後のほうは実例がいくつか上がった。
- ドイツのAir Safety Law
- 自動運転
- 技術は中立たりえるのだろうか？
- コンピュータシステムは、橋を作ることとどう違うのだろうか？
- BitCoinの話
- ICE's expert system and always detain ?? ICEとは何だろう
- 「審判するシステム」としてのMLとAI
- Facebookの問題
- エンジニアは正しいことをしたいと基本的には思っているが、以前の調査によると、求められれば状況に応じて意にそぐわないことをするエンジニアが4割もいる
出典:
Stack Overflow Developer Survey 2018
3日間を終えての総括
海外カンファレンスに行く意味を自問している自分もいましたが、行って帰ってきて思うことは、シンガポールという場所で環境変えて集中してひたすらインプットして、そしてそれをいろいろ調べながらアウトプットして、という普段やらないことを徹底してやり続けた3日間でものすごくリフレッシュしました。
自分が何か貢献できるとしたら今回得たものをアウトプットすることなのかなと思います。
ブログ記事を書いたり、どこかで話したり、業務に生かしたり、次回は登壇する側に回ったりなど。
本記事がその1つとして誰かの参考になればうれしいです。
