SREcon19 Asia/Pacific 参加レポート

2週間ほど前にSREcon19 Asia/Pacific に行ってきました。何気に海外カンファレンス初参加。というわけで出張レポートです。

会社への提出レポートも兼ねているため、旅行的成分は少なめでお送りします。

カンファレンス概要

発表資料は現時点でもすでにProgramページに添付されていっている。 動画に関してもいずれ公開される予定のハズだ。

セッション内容

1st day

  • Use Interview Skills of Accident Investigators to Learn More about Incidents
    • 面接で使う質問力を用いてIncidentの原因究明に活かそうという話
    • 面接 -> Incidentという展開だけでなく、Managerの1on1にも通じる、あるいは使える話だった
    • Open Questionで相手から引き出すように心がける、などの話も盛り込まれていた
    • Templateを用意するのは面接のクオリティを担保したり、運用コストを下げるのに効果的だが、ポイントとしては Don't follow template の点もあったり工夫が見られた
  • Leading without Managing: Becoming an SRE Technical Leader
    • 結論から言うと、今回聞いた中で個人的なベストはこれ。Individual Contributorも、Tech Leadも、Engineeering Managerも皆見てほしい
    • Engineer Career Ladderの紹介もあり、その区分けが影響力によって上がっていくというのは弊社と一緒。その 影響力 をより具体的なケースで述べている
    • Task Drivenから始まり、Project Drivenになり、周りを巻き込みながら成果を大きくしていくのはしっくりくる
    • そうやって成果を出した Tech Leaderこそが 「They can change process」というのがカッコ良い
    • Be the someone in "Someone should"(= 皆が「誰かがやるべき」と思う【誰か】になる のが意味のある仕事であるというのは勇気づけられる言葉だ
  • The Bloomberg Story: Building SRE Teams in an "Immeasurable" Organisation
    • メルカリのMicroservices化にコミットしている人には見てほしい内容
    • 3年で500人以上のSRE組織にしていった話
    • メルカリと同様、Centralizedな体制で始まり、現状は半分がFeature開発チームにEmbeddedしている模様
    • 当然Centralizedな良さもあり、Infraが安定していることなどはその一要素、その通りだと思う
    • 組織拡大の過程にはInternal Transferもあったようで、これもメルカリが狙う形と同じ
    • ただしSRE mindset はとても重要だし、それもあって外部採用もできてくる
  • Retrospectives for Humans (a Crash Course)
    • ある意味日本ではそうそう聞けない「世界各国における英語の解釈の違い」について
    • 対立構造を生まない、とか断定系の表現はしない、とか言語が違っても気をつけることは一緒
    • また、SRE本にもあるPost Mortemのポイントとして「人間が頑張る」対応策はNGの話もあった
    • さらに「ヒューマンエラーは問題の根本原因にはならない」と断定しているのは素晴らしかった
    • おもしろかったのはJokeの使い方の例があったこと。この辺は日本ではないかもしれない
    • まとめると、コミュニケーションの問題は万国共通であり、この規模のカンファレンスでも取り上げられるほど大きな課題なのも万国共通なのだなぁ、ということ。
    • 特にメルカリはGlobal Tech Companyを目指す中で様々な課題に直面しているけど、きっとどこの会社でもある、あるいは乗り越えてきた課題なのだろうと思わされる内容だった
  • Releasing the World's Largest Python Site Every 7 Minutes
    • Instagramのデプロイの話
    • とても歴史的経緯が感じられる良いコンテンツだった
    • まず、おそらくInstagramがモノリスリポジトリであるということ、アーキテクチャもオーソドックスなデザインであり、Djangoのアプリを本番にrsyncして、symlink切り替えてデプロイしている、ちなみに金曜日は安全のためにリリースしない、みたいな感じっぽい。それだけ聞くとInstagramもどこにでもあるwebサービスと変わらないのだなと思わされる
    • それがFacebookの後ろ盾を経て、大規模かつスピーディーに行われているというのが凄さ
    • 驚くべきことにステージング環境がなく、開発されたものは本番にcanaryリリースされて検証される。その目的がtrunk(master branch)を壊さない事。そのため、開発用のブランチでコードレビューが通ったものからcanaryリリース対象になる模様
    • モノリスのメリット/デメリットをそれぞれ考慮して対応し、かつそれができているというのが最もおもしろかったポイントだ。今メルカリはMicroservicesを選択し、自分もそれに向かって挑戦しているが、やはり答えは一つではないなとも思わされた。Miicroservices化は否定しないし、これからも推進していきたいがこれはこれで多くの学びがあった。

2nd day

  • Critical Path Analysis—Prioritizing What Matters
    • アジア版Uberとも言うべきGrabのサービスにおけるクリティカルポイントを考えた開発について
    • お金をやりとりするサービスで、お金が直接絡む機能とそうじゃない機能で重要度が違う、というのが一つのポイントだったように思う。そしてそれはメルカリもそうだな、と通じる部分を感じたのが印象的。
    • 逆に言うと、捨てるポイントを明確にするのも重要。
    • 「Developer focus to feature」というのは本当に同意で、Platform Teamもそれを目指している
    • Graceful Degradationの項目で、静的データはCaching効かせやすいみたいな話もあって、そうだよね～感が満載
  • Cross Continent Infrastructure Scaling at Instagram
    • こちらもInstagramの話。アジアのイベントなのに、データのBackup for DRに大陸をまたぐ話をヨーロッパとアメリカ大陸が舞台なのはちょっとおもしろかった
    • Cassandraの運用の話で、複数のDCにデータを持った冗長構成、でもヨーロッパでは2拠点しかないので、レイテンシを考えて東海岸も同じRegionとして扱う、とかスケールデカすぎ
    • 1日目のデプロイの話はスタートアップっぽさが残る話だったが、こっちはガチのGlobal Scaleだったのでそこそこギャップがあった。ので、登壇後の発表者を捕まえて聞いてみた話は後述
  • How to Champion SRE Investment to Different Levels of Leadership
    • What,Whyはあえて置いて、HowにFocusした内容だった
    • Individual Contributorの人に見てほしいかも
    • とてもインタラクティブな部分を重視していて、最後にセッションの内容をクイズ形式でおさらいするなどの取り組みがおもしろかった
  • Distributed Sys Teams
    • Fastlyにおけるリモートワークが超いい感じだぜ！っていう話
    • 「it's easier said than done」と途中で出てくるのだが、聞いていて「いやー、これすごいけどホントにできてるの？どうやって？問題起きてないの？」と思わざるを得なかった
    • 個人ごとのパフォーマンスのための非同期性を活かしつつ、チームワークとしての同期性（チャットよりビデオ、時には雑談だけのビデオコミュニケーションも）を意識しながらやる、っていうのは確かに大事な事だが言うより難しい
    • これを実現するために大事なことは、集合チームと一部のリモートチームみたいな構図だとうまくいかなくて、どうしても集合チームが主体になりがち。それは力関係の問題ではなく、雑談してる中でやる事が決まって、みたいな流れで物事を進んでしまうことが自然にある。それを意識的に避けないと成功しないと思う
    • Platform Team も1人だけ離れたオフィスで働いていて、上記のようなリモートから見たサプライズな動きがないように気をつけている。具体的には議論はissueを作ることから始めているので、知らなかった話というのは基本的にないハズ。issueの進捗が雑談の議論を元に進むかもしれないが、それもissueを見ていればキャッチアップ可能なハズだ。
    • あるいは、マネージャーとしてはリモート側の声はよく聞くようにしていて、先日もチーム全体の定例MTGの頻度を減らして業務効率を上げる取組をしてみたが、チームとしての一体感に対して懸念が上がってきたのがリモート側が早かったので、定例の頻度を少し戻すというのは即時に判断した。
    • いずれにしても、Fastlyの状態はすぐには実現できなくて、そのためにはまずマイノリティリモートチームを作ってワークさせないといけない。大体のケースがここで失敗して、その先に進まないっていうクエストなんじゃないかと思うので、難しいけど良い話だった

3rd day

  • Lightning Talks
    • ここは Platform Teamとして一つのハイライトであり、@dtan4 による発表を見るのがメインミッションだった
    • 10人以上のLT発表者から事前にスライドを集め、1枚15秒で自動ページ送りする形式で固定、発表者間に特に区切りのスライドはないので、ドラが鳴ることもなくどんどん進んでいくLTだった
    • そこまで自由が効かない状況で、Platform Teamがこれまでなぜ/どうやって取り組んだかをコンパクトにまとめて発表していたのがステキだった

speakerdeck.com

  • Ethics in SRE
    • これが大トリのセッション
    • これに関しては、わかったことじゃなくて「わからなかったこと」の話
    • 正直倫理という話題について、ネイティブスピーカーの人が息切れしながら話す英語を聞き取り・理解するのは俺の今の語学力では不可能だった。完敗。
    • 後述するが、はっきり言って理解できなかったセッションもあり、最後のこれもその一つ。もちろん事前に予想していたことだが、この「わからない」という学びは大きかった

その他聞いたセッション

セッション内容以外について

ダイバーシティ

会場に女性参加者の数が多いことに驚いた。各社必ずいるし、集団を成しているところもある。日本でSREやインフラのイベントをした時、一体どれだけ集まるだろうか・・ 具体的な数値で、Googleの人と話しをした時、シドニーオフィスでは100人以上のSREがいて、うち20%は女性だそうだ。結構驚きの数値だと思う。

セッションへの参加率

YAPCのAsia以外だとセッション聞かずにコード書いているだけの人とかいるようだが、フロアをウロウロしている人は少なかった気がする。ただ、そもそもの参加率として3日目とかは空席多いなとは思ったので、徐々にドロップアウトしているようには感じられた。 その辺は参加費も影響しているのかもしれないが、さすがにそれなりの額を出しているだけあって

  • そもそも会場が豪華。日本で言うなら、ビックサイトか国際フォーラム的なところ。
  • セッション切り替えのたびに各席に水が補充される
  • フロアではコーヒー飲み放題 + 軽食
  • ランチ・懇親会もしっかりしたものが提供された

あたりは流石だなと思った。電源タップの数が少ないくらいしか不満はなかった。あと、会場がクソ寒かった。

発表のうまさと話のスピード

やはり発表に慣れている人はゆっくりしたスピードで聞き取りやすかった。一方で、慣れてない訳ではないのだろうけど、かなり本気で喋る人のはさすがに聞き取れなかった。。特に技術系の話であれば、スライド内にコードが載せられて雰囲気が掴める、とかも期待できるが今回は特に技術系トークではなく、組織だったり考え方を聞くようなセッションをずっと回っていた。その系統だと抽象表現のスライドのパターンも多く、50分のセッションの開始5分で、「こりゃ無理だ」と思ったものがあったのも事実だ。 一方で、特徴的におもしろかったのは初日のInstragramの人で、おもいっきり原稿を顔の前に持っていって読んでいた。あそこまで潔い判断もできるのか、というのは驚きだった。

カンファレンス参加とレポーティング

少し上で参加費について触れたが、それ以外にもフライトチケット・ホテル等の費用があってカンファレンスに参加してきた。その費用についてはすべて会社が負担してくれた。これには素直に感謝しており、それには応える必要があると思っている。その手段としてこういうカンファレンスレポートがある訳だが、実際どういう項目を書くべきか？

個人的には、セッションのメモをひたすら取っただけのレポートは意味がないと思っている。今や大体のカンファレンスが、資料は発表者が公開するか、あるいはカンファレンスページにリンクされ確認できるし、セッション内容を録画した動画すらも公開される（今回のSREconもそう）。それだけの一次情報に容易にアクセスできる中で、第三者のメモにどれだけ意味があるか。。速報レベルで公開するか、発表者以上に資料に対して補足が述べられるくらいのアドバンテージが必要になると思う。

では何を書くか？個人的に得られた経験をそのまま書くのが良いと思う。特に現地に行ってしかできない経験をしてくるべきで、他の参加者と話す、コネクションを作る、イベントの内容ではなくその場から感じた事を伝える、などかと思う。 例えば感じたこととして前述のダイバーシティの件など、メルカリとして目指すところについて他社と乖離があるのを伝えるのは必要だと思ったので書いたし、他の日本人の方でもセッショントークをしている方がいたというのも「遠くでやってるイベント」じゃないというのを伝える意味では書き残しておくべきかと思う。

という思いは持っていたのだが、ちょうどGoogleの人と話した時にどうしてるのか聞いてみた。 基本的な考えは同じで、参加者全員で一つのGoogle Docsを共有していて、セッション内容などはセッションごとに各人が情報を書き足していく運用らしい。それも内容のメモというよりは、それを見てどう思ったかを各自が書いているようだ。

Shared Docsはなるほどな、と思いつつ基本的な考え方がマッチしていたのは個人的に嬉しかった。

Discussionした情報アレコレ

マレーシア在住のエンジニアの方々

こちらが参加者パスに「We are hiring」のシールを貼っていたおかげで話しかけてもらえた。 採用しているよ、と言ったのだが「どこのオフィス？」「東京だよ」「あー、そう、OK、ありがと」みたいな感じでかわされてしまった。多分シンガポールオフィスの企業を狙っているのかなぁという印象で、まぁ開催現場ということもあるがAsia/Pacificの中心は東京よりもシンガポールにやはりなりつつあるのかも、と少し考えたりした。

カリフォルニアのGoogle SRE

Youtube Adsをやっている人。それだけで数千人のエンジニアがいるっぽい。 GoogleのSREは、開発チームが自チームのheadcountを消費してアサインされている。 開発チームとしては、開発するためにSWE(SoftWare Engineer)を増やすか、信頼性のためにSREを雇うかを選択する形になる。
という話は以前にも聞いていて、休憩時間で話してこの辺の話題で終わってしまったのが残念。 ここでも英語力の壁に阻まれて、まだ聞いたことない部分に踏み込めなかったのが惜しかった。

Instagram の発表者

2日目のセッションの発表者。 初日のセッションがInstagramのスタートアップ的側面を強く残した内容になっていたのに対し、とてもスタートアップに所属していたエンジニアがやるのとは大きく毛色の違うスケーラビリティの話をしていたので、「スキルセット違うと思うけど、スケールに関することはやっぱりFacebookエンジニアがやるの？」と聞いてみたらそうらしい。先のGoogleの例とは違い、Instagramから見てFacebookはセントラルなインフラ部門っぽく見えてるようで、必要に応じてサポートしてもらえるようだ。Googleのように、headcount使って来てもらうというよりは、所属はお互い違うままで連携しているっぽいことを話していた。 この辺りも各企業ごとに文化や仕組みが違うので、正解は一つじゃないなぁというのを再確認できた。

まとめ

一言で述べるなら「全く知らなかった新しい発見はなく、それが良かった」となる。 もちろん各社の人と話して得られた気づきはある。一方で、セッション内容でいうと、自分たちができていること/できていないけどやりたいこと、がほとんどのように感じられた。もちろんできていないのだけれど、だからこそ今のやり方を続ける事は案外間違ってないなと確認することができた。

もう一つは英語力で、やはり聞き取れなかったセッションは悔やまれる。日常においてメンバーと英語でコミュニケーションすることも英語学習のモチベーションの一つだが、貴重なカンファレンスの機会に逃さずそれを聞きたい、というのは次回参加までの目標になった。 アジア開催は時差もほとんどなく移動も長くないし、行きやすくて良かった。SREcon自体は各Regionで行われているが、とりあえず来年のAsia/Pacificにはまた参加したいなと思えた。