SREcon19 Asia/Pacific参加メモ: 3日目 と総括

3日目(最終日)のメモです。各セッションを振り返ったあと、総括をします。

How We Used Kafka to Scale Database Infrastructure

LinkedIn内部で使われているドキュメントデータベースであるEspressoについて、Kafkaを使ってデータのレプリケーションをどう行っているかを解説したセッション。

f:id:road288:20190616003924p:plain:h200

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の職務全般と母の仕事にも共通点が多い。

f:id:road288:20190616004157p:plain:h200

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つに対して接続させるようにして、それがうまく均等にできればリソース効率が良い状態にできる。その際に考慮に入れるのは接続先に対するレイテンシと、接続先の負荷状態。

セッションでは、どのようなアルゴリズムを試してきたかを紹介し、 現在たどりついたベストの実装について述べていた。

f:id:road288:20190615105804p:plain:h200

自分の理解では、図のようなリング(輪)のトポロジで、各サーバーをリング状に均等に割り振り、それを接続元・接続先を一緒の円として重ねたときに重なる部分がそれぞれの接続元が接続先につなげるときのサブセットとして決まる。

それを一回決めるだけならそれほど難しくないが、次のチャレンジはそれを継続的に行うことだ。サーバーは数が増減するしトラフィック量も負荷状況も変化していく。各サーバーが次のリクエストで接続先を選ぶときに中央で管理するのではなく個別に(discrete)判断して、それがうまく推移的になり、結果的にランダムに配分されている、それがResiliencyといえる。そうしたアルゴリズムの詳細についての解説だった。

High Availability Solution for Large Scale Database Systems

Baiduのエンジニアによる、超大規模のMySQL運用において高可用性を保障するための工夫について述べたセッション。

f:id:road288:20190615111540p:plain:w250

BaiduにおけるMySQL利用の規模はかなりのもので、1万ノード以上、ペタバイトのデータ量、複数のクラウド利用およびハイブリッド、MySQLバージョンの混在など、運用が大変なため、自動化の必要性に迫られていた。

これだけあると故障は日常的にあるので、HA構成をきちんと取らないといけないが、Baiduでは決済取引などのクリティカルな用途にもMySQLを使っているので、ノードのFail検知や復旧後のデータの一貫性については譲れない要件だった。さらに規模の大きさから同時並行で処理ができる必要があり、既存のソリューションであるMHAMMMではその要件を満たせなかったとのことだった。

Baiduで採用したアプローチはXAgentというプロセスをすべてのMySQLノードに配置して管理するというもの。設定を注入するノードは別途いるが、XAgentはそれぞれ個別に協調動作し、SPOFは無い。

さらに、ノードのFailを検知する仕組みについても解説があった。「ノードがFailした」と一言でいってもさまざまな状況があり、一時的に負荷が高くて応答しないだけかもしれないし、ネットワークのレイテンシが高いだけかもしれないなど、ミス検知してしまう可能性はいくつものケースが想定される。そこでBaiduでは3レイヤーに分けて検知のアルゴリズムを組み、ミスがないようにしているとのことだった。

f:id:road288:20190615112740p:plain:w250

次に、フェイルオーバーの際にデータの一貫性をどう厳密に保障するかという話があった。 フェイルオーバーといってもレプリーションのやりかたが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
  • 自動運転
    • TeslaもUberも倫理的課題を抱えている
  • 技術は中立たりえるのだろうか?
  • コンピュータシステムは、橋を作ることとどう違うのだろうか?
    • この問いかけは何度も出てきた
  • BitCoinの話
  • ICE's expert system and always detain ?? ICEとは何だろう
  • 「審判するシステム」としてのMLとAI
  • Facebookの問題
    • 民主主義や国に対して大きな影響を与えられる存在
  • エンジニアは正しいことをしたいと基本的には思っているが、以前の調査によると、求められれば状況に応じて意にそぐわないことをするエンジニアが4割もいる

出典:

Stack Overflow Developer Survey 2018

f:id:road288:20190616005101p:plain:w250

  • SREは「Watchers on the wall」(壁の上に立つ見張り番)ではないだろうか?
  • 私たちができることは何だろう?
    • 倫理上の取り決めに沿ったレビュープロセスを持とう
    • 異議を唱え(dissent)よう
  • IEEE Guidelines for Engineers dissenting on ethical grounds
  • 個々のコンパスを持とう

3日間を終えての総括

海外カンファレンスに行く意味を自問している自分もいましたが、行って帰ってきて思うことは、シンガポールという場所で環境変えて集中してひたすらインプットして、そしてそれをいろいろ調べながらアウトプットして、という普段やらないことを徹底してやり続けた3日間でものすごくリフレッシュしました。

自分が何か貢献できるとしたら今回得たものをアウトプットすることなのかなと思います。 ブログ記事を書いたり、どこかで話したり、業務に生かしたり、次回は登壇する側に回ったりなど。 本記事がその1つとして誰かの参考になればうれしいです。

SREcon19 Asia/Pacific参加メモ: 2日目

昨日の記事の続き。2日目について書きます。

帰国してからきちんとまとめようと思ってもだらだら遅れる気がするので、昨日とは違って現時点でのメモをどばっと吐き出したいと思います。

Reliable by Design: Adding Value in the Design Review Process

f:id:road288:20190614073722p:plain

システムアーキテクチャ・ソフトウェアのデザインにおいては、後々後悔する意思決定があるので、きちんとデザインドキュメントを書き、レビューをしようということで、チェックリスト形式でレビューすべき点を紹介したセッション。

Who, what, why(誰が、何を、なぜ)
  • ゴールは何か? 必要な人がレビューをしているか
  • プライバシー・セキュリティ・悪影響を与えるシステムはないか
Alternatives Considered(他の選択肢)
  • 他の選択肢を十分検討したか?
Stickiness
  • システムの中でどの部分が今後変化する可能性があるか?逆に変化しないところはどこか。
  • アーキテクチャがデータモデルに織り込まれているか?
Data
  • データの一貫性が求められるのはどこか、アーキテクチャがそれを反映ししているか
  • 他のデータによって変更されるもの、そうではないものはどれか
  • データのSLO, 保持期間, 暗号化, レプリケーション, シャーディング, バックアップ, アクセス制限, GDPR等プライバシーへの対応 
Complexity
  • それぞれのシステムコンポーネントは役割が明確か。数を減らすことはできないか。似たものがないか。新しい依存関係を生んでいないか。
Scale and Performance
Operability
  • 監視がやりやすいデザインか(やりづらいデザインもある)。
  • サードパーティのツールで監視できないか。
  • オペレータにとってわかりやすい・使いやすいツールか
  • ルーチンワークはToilになる。誰がやるのか。自動化してしまうことでオペレーティングチームのシステム理解度が下がることもある。
  • Abusiveなリクエスト・ユーザーへの対応を決めておく
  • 外部ベンダーはこちらの機能リクエスト・問題に対応してくれるか
Robustness
  • 物理的故障が起きたときにどう対処するか
  • ネットワーク分断・レイテンシの上昇にどう対応できるか
  • 復旧のために必要な手動のオペレーションは何か
  • システムをオペレータ自身が壊してしまうことができるか。一般ユーザーからそのパスが切り離されているか
  • 分割可能な単位は何か。依存関係は何か。Gracefulに縮退させられるか
  • ゼロから再起動できるか。どれくらいの時間がかかるか。その際システムの依存関係がないか。DNSと監視の考慮も忘れないこと。
  • ロードのスパイクに対応できるか
  • キャッシュは使っているか。キャッシュを使わなくてもさばけるか
  • Control PlaneとData Planeは分離されているか
  • Canaryデザインについて。システムに負荷をかけないか。
  • システムが自らに負荷をかけてしまうような悪循環に陥るポイントはないか。

Edge Computing: The Next Frontier for Distributed Systems

Fastlyの人が、といっても会社とは直接関係ないトークだ、とことわったうえで、Edge Computingの基本と今後の可能性について述べたセッション。

エッジコンピューティングとはオリジンサーバーでレスポンスを作って返すのではなく、もっとユーザーに近いロケーションにあるシステムによってレスポンスを作って返すことをいう(少なくともこのセッションでの定義)

ユーザーに近いといってもどこか。いくつかポイントがある (↓上から下に行くに従ってユーザーに近くなる)

  • Origin Server
  • Continental Region
  • Data Center in Major cities
  • ISP
  • Last mile 例えば携帯電話の基地局とかの想定と思われる

次のリクエストが異なる○○によって処理されることを想定したシステムが必要。

  • 異なるプロセス
  • 異なるサーバー
  • 異なるクラスタ
  • 異なるプロバイダー(AWS/GCPみたいなクラウド提供者を指しているか?)

下記のような考慮が必要

  • リクエストの標準化
  • 認証でやるのか、Paywallでやるのか(このPaywallという文脈がわからなかった。課金ユーザーのみ許可するアクセス制限とかそういうイメージかと)
  • ユーザーエージェントによって異なる処理
  • ローカライズ
  • A/Bテスト

  • Fastlyが提唱している WASI というフォーマットについて紹介

  • データのReadだけエッジでやって、Writeは中央(Origin)でやるのか、それともReadもWriteもエッジでやるのか

  • デプロイはどうするか、設定の変更はどうやるか、ファンクショナルテストや負荷テストはどうするか

発表資料

TCP—Architecture, Enhancements, and Tuning

TCPの基本からチューニング、さらにはQUICまで、内部実装を紹介しながら今後の進化について述べたセッション。

このへんは部分的には理解しているが、体系立てて説明できるかというとできなかった分野で勉強になった。再度復習したい。

  • OSI参照モデルの説明(L1~L7まで)
  • その中で、L4レイヤー、つまりTransport Layer(TCPの部分)の深掘り

  • Transport Layerの課題と必要な要件について

    • 順序が保証されていること
    • ステートフルであること
    • 帯域のコントロール
    • Multiplexing多重化
  • TCPのコアコンセプト

    • Sequence番号を持つ
    • コネクションを張る
    • Window Sizeを持つ
    • Port番号を使う
    • Ackをする
  • TCP Headerの中身の説明

    • Window Size
  • Retransmission 再送処理の説明

    • Syn, Ack, Retransmission Timer
  • TCPの拡張

    • スロースタート
    • Congestion Avoidance(混み合うことを防ぐ機構)
    • Fast Retransmission(早い再送処理)の仕組み. Recv側から再送リクエス
  • TCPのチューニング

    • Bandwidth delay product(帯域遅延積と訳せるらしい、ちゃんと理解できていない)
    • Bufferのチューニング, Selective Ack, MTU Probing
    • Initial Congestion Window
      • initcwnd を増やすことでラウンドトリップを減らす
  • Congestion Controlのアルゴリズム

  • QUICの紹介

    • TCP/TLSを(一部)置き換えようとしている
  • SCTPについて

BGP—The Backbone of the Internet

f:id:road288:20190614083237p:plain

BGPの紹介。歴史、実装、プロトコル、実際の例をあげての説明。

自分が特に弱い分野で意味のあるメモを以下に書ける気がしないのでセッションの結論だけ。

  • BGPはインターネットのメッセージバスである
  • よくスケールするが、全部を網羅することはできない
  • 実装が複雑なので、全部を理解するのは困難

Linux Memory Management at Scale: under the Hood

Linuxのメモリ管理についてのセッション。

下記の画像はfbtax2を使った際にメモリの利用が改善された例の紹介

f:id:road288:20190614084707p:plain

Ad Hoc SSH Access Using Signed Tokens

SSHアクセスを、従来の公開鍵を接続先のサーバーに置く必要なしに、CAとx.509を用いて必要なときに一定時間だけ必要なサーバーにSSHアクセスを許可する仕組みの説明。OSSではない模様

下記の画像が端的になんたるかを表しているので詳細は割愛

f:id:road288:20190614085117p:plain

Software Networking and Interfaces on Linux

f:id:road288:20190614090411p:plain

ネットワークの基本から、インタフェース、ブリッジ、最新のトレンドまでを紹介するセッション。

EthernetARPの紹介から始まり、vLanやIptable、NATやRouteテーブルの紹介などまでは良かったが、tun/tapが出てきたあたりからついていけなくなり、virtio_net, veth, ipvlan, macvlan, calicoなどまで説明して後半はふむふむと聞いてるだけ。完全に打ちのめされた。このへん理解が浅すぎて勉強しないと...

  • インタフェースまとめ
    • Loopback
    • Dummy
    • "real"
    • multiple L3 addresses
    • TAP/TUN
    • vEth
    • VLAN
    • Macvlan, macvtap
    • Ipvlan, ipvtap L2
    • Ipvlan, ipvtap L3

↑この辺あとで調べ直す。

セッション動画は下記に上がってます。

mt165.co.uk

Automating OS/Platform Upgrades for Service Owners

Pinterestでの実例から、SpinnakerのCanary機能を用いてOSやプラットフォームごとアップグレードする事例の紹介。

アップグレード前後で比較すべきキーとなるメトリクスを用いて、Canary機能を使って試験的に一定時間デプロイしてメトリクスを収集して、アップグレードをそのまま全デプロイしてよいかを判断する。意思決定フローの都合もあって手動承認する部分を残している。

f:id:road288:20190614091055p:plain

仕組みとしては分かる。だけどこれを実際にやるのは大変なはずで、これを仕組みとして回しているというのはとても励みになる。

Unified Reporting of Service Reliability

GCPの中の人による、GCPの障害やユーザーサポートの情報を集約するダッシュボードのアーキテクチャの紹介と、それをどう運用しているかの事例の紹介。

前半はデータをどう集約してダッシュボードを作っているかという話で、Entity RelationshipとStar Schemaに基づいたデータモデルを作っているということで、DWHとしては正攻法なやり方をしていると思った。そこからSQLを多段でごにょごにょしてダッシュボードとして提供している。

後半は、そのデータから得たインサイトをどうアクションにつなげえているかという話で、下記の話が一番印象に残った。

  • SLI/SLOは、Customer Happinessと連動しているのか?相関を調べて、ミスマッチであれば、SLI/SLOを修正する。

  • Monitoring/Alertのタイミングより先にユーザーからのIncidentレポートが上がっていないか? そうであれば、Monitoring/Alertのほうを修正する。

f:id:road288:20190614091420p:plain

全体的に熱量がある話で、こうしたDWHとそこからインサイト、アクションへとつなげるというのはハードルがいろいろあるが、「標準化せよ」「自動化せよ」「ビジョンを持って最初のやり方がうまく行かなくても失望せず続けよ」と締められていて、後味が良かった。

2日目は以上です。

なお、下記のブログ記事にも2日目の様子は詳しく紹介されています。

SREcon Asia/Pacific 2019: Day Two - danrl.com

SREcon19 Asia/Pacific参加メモ: 1日目

2019/6/12~6/14にシンガポールで行われているSREcon19 Asia/Pacific(以下SREcon19AP)に参加しています。開催場所はシンガポール市内のSuntec Singapore International Convention & Exhibition Centreです。

SREconはSite Reliabilityの話題を中心に、DevOps、分散システム、OSやネットワークのデバッグ・チューニングなどがテーマで、特定の技術にフォーカスしていないぶん、幅広いトピックがあるカンファレンスです。

f:id:road288:20190613084053j:plain:w200

今回のSREcon19APは、セッション内での発表によると参加者は580人(125の企業、24カ国)だそうです。Google/Microsoft/Facebook/Baiduなどの業界を代表する大企業を中心に、ユーザー企業、ツールベンダーなどバラエティに富んだ参加者の印象です。日本からも十数人の参加者がいます。

開催期間は3日間で、3トラックで同時進行し80くらいのセッションがあります。その他はランチ・レセプション・スポンサーブースなどがあり、一般的な技術カンファレンスの構成です。

私は現在、株式会社サイバーエージェント・アドテクスタジオのエンジニアとして、インフラ部門のチームに所属していくつかのプロダクトのインフラ構築・管理・オペレーションなどを行う仕事をしています。”SRE”という肩書ではありませんが、実質的にSRE的な役回りをやっていることも多くあり、幅広い視野と一段高い視点を得たいと思ってこのカンファレンスに参加しました。

現地にいる間に感じたことを速報・メモ的に書き留めたいと思います。

f:id:road288:20190613084121j:plain:w200

全体の所感

SREというポジションは、特定の技術領域を指しているものではないので、技術カンファレンスとしてはガチガチの技術トピックというよりは、アプローチ・マインドセット・組織づくりなどに関する内容が多い印象です。 例えば、現在アプリケーション実行基盤としてデファクトスタンダードになっているKubernetesを正面から取り上げたセッションはありませんし、プログラミング言語をタイトルに冠したセッションもJavaが1つ、Pythonが1つという感じでバラバラです。 ただ、ふわっとしている内容なのかというとそういうわけではなく、それぞれの内容を具体的に応用可能な知見にするための方法論が話されている印象を受けました。 多数の言語・多数のミドルウェア、インフラ基盤に接している私の今の状況にはフィットしていると思いました。

f:id:road288:20190613084534j:plain:h200

各セッションの一行所感

参加したセッションを端的に紹介していきます。

A Tale of Two Postmortems: A Human Factors View

2つの「あるあるな」障害振り返り(Postportem)の事例を紹介しながら、どこに注目すべきか・ありがちな落とし穴・注意点などを考察。

Availability—Thinking beyond 9's

99.99%」「99.9999%」などの9を並べたSLA/SLOの定義をあらためてまとめつつ、Failureの定義は何かとか、誰がその指標を使うのかといった視点から可用性(Availability)について考察。

f:id:road288:20190613084941p:plain:h200

Use Interview Skills of Accident Investigators to Learn More about Incidents

システム障害後の調査のため関係者にインタビューする際のノウハウをまとめたセッション。基本的には「彼ら個々の頭にあるストーリーを語ってもらうこと」を推す内容。

Leading without Managing: Becoming an SRE Technical Leader

SREとしてのキャリアを、いわゆるマネージャとしてではなく、テックリードのポジションで上を目指すための具体的な方法論・取り組むべきことについて紹介。LinkedInでそのポジションにあり、Kafkaについての著書もあるなど実績もある方の話でとても説得力・具体性があった。

f:id:road288:20190613085132p:plain:h200

Practical Instrumentation for Observability

「Avalilability」「Latency」「(Service/Product)Quality」の3つに焦点をあて、Observability(可観測性)の基本をあらためておさらい。基本的な内容かもしれないが実際はできてないことばかりで頭が痛い。

f:id:road288:20190613085415p:plain:h200

Let's Build a Distributed File System

ファイルシステムの基礎からはじまり分散ファイルシステムアーキテクチャについて述べ、簡単なデモ用OSSPyDFS」を例に分散ファイルシステムの具体的な実装を紹介。

Ensuring Site Reliability through Security Controls

Paypalのエンジニア2人が登壇。Malicious(悪意のある)トラフィックを遮断するためのL7レイヤーでの検知および対処方法について紹介。このあたりは既存のWAFソリューションを入れるとあとはお任せみたいにしてしまうこともありがちで、具体的に中身について考えられたのは良かった。

f:id:road288:20190613085627p:plain:h200

Why Does (My) Monitoring Suck?

モニタリングはなぜ難しいのか、そしてどう改善すべきかの具体的な方法論について紹介。結論としては「SLOを定めよ」「アラートを整理しろ」「メトリクスを取るための仕組みを導入せよ」。

Enhance Your Python Code beyond GIL

PythonのGIL(Global Interpreter Lock)について紹介し、それを前提にしつつpythonでの並行・並列処理をうまく実装するための選択肢(multithread/multiprocess/ASyncIOおよびその組み合わせ)について紹介。

f:id:road288:20190613085806p:plain:h200

1日目は以上です。 残り2日間も追って投稿します。

VPCエンドポイントについて整理

あとで復習用にメモっておく

devlog.arksystems.co.jp

VPCのネットワークにはコンポーネントがいくつもあって、混乱しやすいので用語の整理。

VPCエンドポイント

「インタフェースタイプ」「ゲートウェイタイプ」の2種類がある。

インタフェースタイプ

Private Linkとも呼ぶ

などが対象

参考:

https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-endpoints.html

昔はVPCのCIDRブロックが重複していると相互接続できなかった。いまでもVPCピアリングはできないが、PrivateLinkを使えば(部分的に)接続可能になる。

ゲートウェイタイプ

  • S3, DynamoDBのときに利用
  • ルートテーブルの書き換えが必要

トラフィックがインターネットを通らないので、データ転送料が安くなる?(どれくらいのインパクトあるかは不明)

ポートとプロセス・ユーザーの関係をss コマンドで把握

ss -ltunp でわかる。

オプションについて:

  • -l Listenしているものを表示
  • -t TCP socketを表示
  • -u UDP socketを表示
  • -n サービスネームを表示
  • -p プロセスを表示

参考 【Linux】lsof、ss、nmapコマンドでポート確認! | 侍エンジニア塾ブログ(Samurai Blog) - プログラミング入門者向けサイト

Evernote, Trello, Google Keep, Scrapbox, Pocketのデータを全部Notionにひとまとめにした

いろいろ使ってたツールを統合してNotionに移行した。

www.notion.so

(↑アフィリエイトリンクです。私のアカウントの無料期間が増える)

  • Evernote(メモ, PDFなど)は組み込み機能でそのままインポート。
  • Trello(タスクリスト)は組み込み機能でそのままインポート。
  • Google Keep(メモ) はGoogle TakeoutでHTMLでエクスポートしたものをインポート。
  • Pocket(ウェブクリップ)はHTMLでエクスポートしたものをPerlでTSVに変換してそれをインポート。
 perl -wnl -e '/\<a href="(.*?)" .*\>(.*)\<\/a\>/ and print "$2\t$1"' fromPocket.html > toNotion.tsv

こんな感じ。CSVインポート機能で、TSVファイルも問題なくインポートできる。

  • Scrapbox(メモ) これがやや厄介。JSONでエクスポートできるのだが、形式が少々特殊なので、
cat fromScrapbox.json | jq -r '.pages[] | [.title, (.lines | join("\n")) ] | @csv' > toNotion.csv

こんな感じでNotionできれいに読み込めるようなCSV形式に変換してやる。

f:id:road288:20190507203308p:plain

全部一箇所に集約できた。

  • タスク管理・カレンダー・メモのストック・ウェブクリップなどを一元管理できる
  • Markdownで書ける
  • ウェブ・Macアプリ・Androidで使える

などの条件を全部満たしてる。デザインもシンプルで良い。

iDeCo, つみたてNISA

前から証券会社にアカウントは持っていたのだが、ちょっとだけ入金したまま放置になっていたので、GWを契機にテコ入れしてみようと思った。 iDeCoとかNISAとかなんとなく知ってはいたが、ちゃんと分かっていなかったので改めて調べてみた。

投資に時間使うつもりはない、ただ勉強はしたい、理解はしたい、やってなくてただただ機会損失しているは避けたいので、最小限の労力でやっておくことができるのであればやってみたいという感じ。

お金は寝かせて増やしなさい

お金は寝かせて増やしなさい

ネットの記事をいくつか読んだのと、上記の本を読んで、インデックスファンドを中心に国内・海外あわせてポートフォリオ作ってiDeCoを申し込んでみた。

現時点での自分の理解だと、

  • iDeCoは所得控除があるので、直近でも節税という点で直接的なメリットがある。60歳以降に引き出せれば良いという点が了承できるのであれば、ただ貯金しておくのと比べてやらない理由がない。
  • NISAとつみたてNISAはそれぞれ微妙に違うが、少額で長く、インデックス投資を中心にということであればつみたてNISAのほうがよさそう。ただこちらは所得控除がないので、投資利益が大きくならないとそこまでメリットがない。
  • ジュニアNISAのほうも興味があるが、それほど投資資金があるわけではないので、いったん一年はiDeCoとつみたてNISAだけでやってみて、副業の税金の金額を見て来年また考える。

最近LinkedInとかに、不動産投資関係の人からコンタクトがちらほらある。投資対象または税金対策としてそれなりにポピュラーなのだろう。

これら以外にも少額ではあるがクラウドクレジットは前からやっている。これはクラウドファンディングに投資するような気持ちでほそぼそとやっている。海外でのビジネスに自然と興味と親近感がわくのでよい。

基本的に健康で居続けることができて、仕事がある限りは引退せず70歳だろうと80歳だろうと働き続けるつもりなので、そこまで老後資金なくてもいいと思っている。ただ、今より収入減るのは想像できるので、それを穴埋めできるくらいまで積み立てておいて、あとは自己投資に全振りしたい。