事例紹介と SREの過去 -> 現在 -> そして

SRE Advent Calendar 2019 19日目の記事です

メルカリ でSREをやっている k-oguma と申します。
ここ2年くらいは、SRE Lounge という勉強会や SRE NEXT という来年2020/1/25(土) に豊洲フロントで行われる日本初のSREカンファレンスの実行委員会を運営しています。
来られる方はよろしくお願いします!!

  • 想定読者層
    • SRE、 SREに興味がある人、SRE的な業務もやっている人、開発組織を束ねる人(CTO, EM, etc)

本記事は、どういった内容か

SREの戦略的な話は以前その SRE Lounge でもさせていただきました。
世の中の流れもその頃とは多少は変わってきているところもございますが、参考程度にはなると思いますので置いておきます。
SRE的team開発Tipsとベストプラクティスっぽい何か

「SREとは」みたいなところは他に素晴らしい記事が今回のAdvent Calendarにも多数ありますので、そちらをご覧ください。
SRE Advent Calendar 2019

今回は、「技術的な側面や具体的な運用事例」や「アンチパターンの説明」と、「私が考えるこれからのSRE」についての記事を書いてみたいと思います。

ちなみに最近の私は SRE的team開発Tipsとベストプラクティスっぽい何か のときに作成した SREs Skill map のベン図でいうと以下くらいのガバメント, ITGC, GDPR などの社内全体のマネジメントレイヤーの設計/開発を継続的に行いつつ、Goで 監視やBotなどのEliminating Toil なものを 開発したり、YAML (主にAnsible, terraform )を書いたり色々やっています。
(トイルについての説明は、弊社EM mshibuya のこちらの記事 トイルについて改めて考える を参考にしてください)

SRE teamとして、他にはどんなことをやっているのか

たとえば以下のようなものを作ったりもしています。

最近作ったもの

最近作ったもので公開済のものを少し紹介したいと思います。
(残念ですが、会社的な都合やライセンス関係もあるわけで全てを公開できるわけではありません。
本当はほとんど汎用的に出来るように作っているので全てOpenにしたいですが..)

Go の Cache package のベンチマークを測ってみた話 にも書いた https://github.com/k-oguma/gce-available-disks (これは、GCPの使われていないdisksを探すCLI tool。aws cliでいう aws --region ap-northeast-1 ec2 describe-volumes --filters Name=status,Values=available みたいなもの) といったものを作ったりしました。

これは所謂、コストコントロールのツールです。
「SREがコストコントロールを行うのか」といったことは「もちろん行う」というよりも「それはどの職種においても責務」なので、細かいことは書きませんが、参考までに以下をご紹介しておきます。
SREとCostについても示されています。

開発ではどのような言語を使用しているのか

開発言語という点で話を続けます。
SREは ToolやBot および 監視pluginなど 運用に関するものを片っ端から開発したりすると思いますが、我々のチームで扱われている言語を使用頻度順で紹介しますと次のようになります。

  • Go
  • Shell Script (bash or zsh)
  • Perl
  • PHP
  • Node.js
  • Python
  • Ruby

我々はこれらの言語を適材適所で選定しています。(一部は使いたかったからというのもある)
しかし、最近は大半をGoで開発するようにしています。
Goなら適した場面が多くあり、運用面も扱いやすく開発速度も実行速度も早いからです。
また、社内にGoが得意な人がいるのもあります。

秘伝のタレ的な 謎の運用Scriptを量産させていくのは アンチパターンである

上記のようにSREとして、1日の半分くらいは開発をする日があります。(残りはOps活動)
私の場合は現在は大半が非機能要件ですが、チームメンバーの中ではプロダクトの開発にも積極的に参加しています。

で、その中でDevOps的なところで注意点があります。
秘伝のタレ的な 謎の運用Scriptを量産させてはならない 」という運用における 定石があります。

Cloud Native な人たちも言っていますし、その何年も前から言われ続けていることです。

なぜアンチパターンなのか


「多くの謎のために 技術的負債が消化出来ず/しづらくなっていて, さらによくあるパターンとして 何年か後には書いた人間がいなくなっている 事も多く、皆が苦しみやがて 新機能開発どころか運用困難な闇の時代に突入する」ことが起こるためです。

"source codeを読めば良いだろ" って?
それは(引き継ぎ含めて)チーム全員が常に読みやすいコーディングスタイルも完璧なCodeを書きつつ、どんな言語でも1000ステップ(行)を10秒で読める場合はそれでも良いと思います。

しかし、そうでないことが現実です。
後々のことを考えて特に重要と思われる情報をまずREADMEかコメントやコミットメッセージくらいは書くようにしてください。
中には本当に何も書かない物が稀にありますが、そういうのは後から引き継いだ人は何を感じるでしょうか。

「どうせ書いても古い情報になると詐欺内容になるから書かない」というのは全てには当てはまりません。
そのものの根底から変わるような変更は起きないはずです。

例えば、極端な例ですが "電車に乗る" という内容が、"バズーカをぶっ放す" に変わるといったようなことはありませんよね?

チームワークとして他のメンバーにも思いやりを持って開発およびReviewを行い、
「信頼性を保つ役割の人間が逆に将来の信頼性を落とすようなことはしないように」心がけることも大切なReliablityです。

その辺りは、CIを使ったり Gitのcommit templateなどを使ったりして、いちいち人が指摘しないでも書かれるようにした方が良いでしょう。
ただし、書きすぎもよくありません。適度に。

...と、いうようなことが様々な会社でも繰り返されてきました。

そしてそういった流れから、Kubernetes や Ansible といった「インフラの定義」で、誰が書いても同じような形式で書かれる/書けるというわけで、リーダブルなInfrastructure as Codeになっていきました。
「Goも記法パターンをあえて絞っている」点では同じ考え方のようです。
なので、我々SREにもマッチしているので積極的に採用をしています。
(昔からGoで開発している人にとっては何を今更な話ですが、Goを使っていない人向けにも説明)

ここまでが、過去そして現在のSRE活動の具体的な一例でした。

これからのSRE

私も未来/先のことを考えることが好きな一人です。

少し過去の時代に遡りますと、
私が記憶している限りでは、2005年頃かもう少し前からインターネットの世界 で "本気の" ITインフラの自律システム (Autonomous system) が考えられていました。(構想自体はもっと古くから)
もちろん当時からバックボーンネットワークのBGPやMANといったMulti Ringで自動切り替えやサーバーの構築自動化といったことは行われていましたが、それらは(中には一部自律的な動きをしますが) Automation であり、よりAutonomous になってきたのは、ここ数年でしょうか。

おそらく理解のしやすいRaft algorithm が注目され、それとAWSでも扱われたとされる Goship protocol を取り入れた Hashicorp の Consul が流行り始めたのと同時に各Cloudが内部的にBlackbox なインフラ部分で自律的な managed serviceを開発、構築していった時代から、最近のAIOpsの流れで 本当の Autonomous system が広がってきていると見ています。
今ではKubernetes や Serverless/FaaS, PaaSといったインフラもかなり自律的に動くようになってきていますね。

そして、これからは皆さんもおそらく予期/予想しているとおり、ML / AI化が急速に浸透していくと考えられます。

そんなことが頭にあったら、本当にたまたま前日の SRE Advent Calendar にそれらについての素晴らしい記事が投稿されたので、そちらもご紹介させていただきます。
class SRE implements interface AIOps ! (多少なりとも被る内容だったので書くの躊躇したくらい)

「そうそう! ITILからの始まり、その流れで今は度々おきているパラダイムシフトの途中!!」って心の中で首がもげそうなほど頷きまくりながら正座で拝読させていただきました。

Automation および Autonomous が普及されたように、AI化の波も避けられるものではありません。

パラダイムシフトが起きる度によく「仕事を奪われる」とか言われていますが、実際にはどうでしょうか。
「馬車が車に変わって..」の時代から、現代の「自動化の普及」において仕事は減ったのでしょうか。
逆にインフラ系の仕事、業務範疇は増えたと思っています。

私は、経済学者ではないので現場の肌感ではありますが、今後もよほどのことがない限り減るよりも逆に増える方が多いのでは? と考えています。
我々も常に起きているパラダイムシフトに順応していくことが必要だと思っていますし、そういった流れは各時代でも繰り返されてきました。

また、SREの本質とはなんでしょうか。
それは名前の通り、「工学を用いて信頼性を保ち、向上させる」ことのはずです。
であるならば、我々の目指すところは その自律システムの設計構築運用をよろしくやって、AIと仲良くしてより信頼性を高めていくことではないでしょうか。

近い将来、全てCloudのManagedでOpsは不要になる?

他もそうですが、まだまだそうはなっていませんね。新しいプロトコルやミドルウェア、アルゴリズムは生まれ続けるし、CloudのManagedだけでは難しそうです。
Managed AIOps で、「Operations as a Service = OaaS/OpsaaS 」といったサービスは生まれると思いますが、その中にも設計構築や運用の面倒を見ないといけないインフラがあると思います。

そういったわけで、MLOps, AIOps もSREが取り入れていくのは非常に重要なことだと考えています。

また、Cloud黎明期の一般予想に反して、上記に示す通り「インフラ系の仕事も増えていっています。」
今からでも遅くありません。 SREがいない会社は雇いましょう。育てましょう!

そして日本でもより一層SREの重要性や価値が認められることを願い、世界にも負けないIT基盤を作っていけたらという思いで、今後も SRE Lounge および SRE NEXT というコミュニティを皆で盛り上げていければと思います。
その運営活動も業界に対する貢献の一つになれば幸いです。

「SREコミュニティ」 がカンファレンスを主催する

コミュニティが主催するカンファレンスについてですが、「企業が主催ではない」ということは「同志 = 自分たちで全ての事を決めて動かないといけない」ということです。
そのためにかなり時間を使います。
私はカンファレンスの企画や準備の傍、財務はほぼ一人で見ているため、仕事中に迅速に応答を返さないと他が軒並み遅れてしまうといったSPOFな自体もあります。

こういったコミュニティ活動も会社やチームの仲間、そしてEM、上司の理解がないと全く出来ないと思います。
この場を借りて、感謝の意を表します。
あともう少しで SRE NEXT 2020 in Tokyo が開催です!!
ご興味ある方は、ぜひご参加ください。
そして今後も皆で盛り上げて続けていけたら嬉しいです!!

会計に強いボランティアスタッフ募集中です!!!!
https://twitter.com/ktykogm もしくは SRE LoungeのSlack でDMください!!
一緒にやっていきましょう!! 私という SPOFを無くしましょう!!

さて、明日は katsuhisa__ さんの回です。
彼が SRE LoungeSRE NEXT の代表で、ともに主催、運営活動を行っています。
お楽しみに!!!!!