SREチームの新設
はい、始まりました。 ツナギメエフエムの第66回です。
ツナギメエフエムは、IT勉強会 コミュニティ繋がりの方々を
ゲストに迎えて雑談するポッドキャストです。
まずは、XQ Twitterの ハッシュタグについてお知らせです。
ハッシュタグはカタカナで ツナギメエフエムです。
投稿待ちしています。
今回で第66回目です。
今日のゲストは、ぞえいさん、そーだいさん、 たけざわさんの3名です。
それでは順番に自己紹介をお願いします。
まずはぞえいさんからお願いします。
はい、ぞえいです。
MillgateでEMをやっています。 よろしくお願いします。
はい、よろしくお願いします。
続いて、そーだいさん、お願いします。
はい、今は株式会社リンケージ っていう会社のCEOと
自分の会社のHubFanticっていう会社で
一人で自宅開発とか技術コモとかを やっています。
そーだいです。よろしくお願いします。
はい、よろしくお願いします。
最後はたけざわさん、お願いします。
はい、日和スターフェスティバル 株式会社というところで
何でも屋をやっています。
あとはいろんな会社で同じく 技術コモとかさせていただいています。
たけざわです。よろしくお願いします。
はい、よろしくお願いします。
はい、じゃあ今日はこんなお三方をお迎えして
なんかちょっと僕がインフラっぽい話を 3人に聞きたいなと思ったんで
ちょうどいいなと思って お呼びさせてもらった感じです。
ということでですね、最近似たようなSREの話題を ツイートしてたりとか
登壇の場があったりとか、そういうブログ記事を 書いてたりしたのをちょっと目にしてたんで
そういった話を聞きたいなと思ってます。
で、最初どの話からいきましょうかね。
うーん、ぞえさんから聞こうかな。
はい。
2021年にSREチームを新設したというところの話を ちょっとお伺いしたいんですけど
これどういった会社の話ですよね、これね。
そうですね、Urigateの話ですね。
前まではインフラチームと開発チームっていうのは
完全にチームとして分離していて
各開発チームっていうのはプロダクトの開発を担当していて
インフラチームはプロダクト横断して 星とかをやるチームだったんですけど
やっぱりそれだけだと信頼性の向上というか、 みたいなのができないっていうのと
あとやっぱり開発とインフラの境目に落ちたような カスクみたいなのがどうしても改善してるのは難しいみたいな
ところが課題感にあったので、それを改善するのに SREチームを新設しようという流れで
2021年に新設したという話ですね。
なるほど。明確にインフラチームではなく SREチームという名を与えたわけじゃないですか。
SREチームのスキルセットとメンバー選び
特にここを変えたとかいうところって何かありますか?
そうですね。インフラとSREをうちは明確に分けているのが
SREってさっきも言ったインフラと開発の狭間に落ちた カスクみたいなのを、ちゃんと情報の都合というか
考えながら改善するみたいなのをミッションにしたかったので、 インフラだけ触るんじゃなくて情報やるっていう
明確な意思を持ってやってました。 両方のスキルセットというか、持っているような人だけを
最初はSREチームのメンバーとして入れて、 改善活動をやるミッションでやったり。
そうそう、まさにそこを聞きたかったんですけど、 スキルセットを持っている人って限られると思うんですよね。
アプリケーションのアプローチの考え方が分かっている インフラエンジニアじゃないと多分できないようなことってあると思うんですよ。
そういった時に、もともといたメンバーのインフラのチームからSREチームを専任したのか、
それともアプリケーション側の人を専任したのか、どっちなんですか?
そうですね、最初はアプリの人の中でインフラの方も ある程度理解がありそうな人を専任してしてあげるっていうのをやってました。
なるほど。
総代さんと竹澤さんに聞きたいんですけど、 そういう人選というか携わったことってあります?
そういったチームを作るみたいな。
僕はCTOやってるから、チーム作ったり役割作ったり考えたりするのは 割と普段からやってるって言うんですけど、
さっき土屋さんも言ってたけど、ボールの間を拾うって、 人間の気持ちというかやる気みたいなのに任せるってやっぱり継続しないんですよね。
だから、仕組み化で解決するっていうので、 チームを作るっていうのもすごい分かるし、
リッケージで言えば逆にエンジニアで言うとソフトウェア側、 バックエンドエンジニア側ができるだけバックエンドのタスクを拾うように、
逆にそっちの力学を強くするみたいなのもあって。
だからSREっていうチームを作るんじゃなくて、 君らはロールがSREじゃなくて、振る舞いとしてSREをやるんだよ。
SREするんだよっていう感じで、 必要なものは自分で用意しましょうっていう感じでリッケージをやったりとかするんで。
ここって答えがないからし、さっき赤瀬さん言った通り、 アプリケーションのことも分かってたりとか、ビジネスのことも分かってたりとか、
結局インフラとSREの間拾えないじゃんって話があったら、 誰でもできる話じゃないんで、
結局他の会社がこうやってるから、僕らも同じようにやれば うまくいくだけじゃないのがすげえ難しいとこだなと。
そうそうそう、まさにそうだと思ってて、 結局今総代さんも言ってたけど、
アプリケーションのことだけじゃなく、インフラのことだけじゃなく、 ドメイン知識もないといけないじゃないですか。
そこがなんか難しそうだなと思ってて、 だから他の会社のSREの方がやられてることが、
実写で実践してもマッチしないことなんて山のようにあって、
なのでSREと一言に言っても、それぞれの会社で 全然やってることは違うじゃないですか。
そこら辺がちょっと難しいよなと思って。
竹田さん、会社でSREのチームってあるんですか?
そうですね、あるところもあればないところとかも、 もちろんあるんですけど、いくつかの会社とか見てるんで、
あるところもあればないところもあるんですけど、 でも今、SREって、
自分のブログにも書いたりとか、よくお話もするんですけど、 いわゆるインフラって捉えるところと、
品質というか、物を良くするために何でもやるぞっていう、 その活動のことを指すのと全然捉え方が違うんですよね。
SREって。でも自分の場合はその後者の方もとにかく みんなでやるぞっていうのをやっていて、
そこと合致する、自分たちのプロダクトをもうちょっと ちゃんと見つめ直したいんだっていうところは、
そういうチームを作って一緒にやっていくっていうことを 今ずっとやってますね。
スキルセット的なところだと、そんなに高度なものは 要求していなくてやっぱり、
SLOとSLIについて
まあちょっと今いっぱい話すと話すことなくなっちゃうので、 あまり言わないですけど。
でもその自分たちのドメインを理解するのはもちろん、 それはもう理解してないと意味がないので、
あとは自分たちのシステムとか、利害関係者って どういうことを期待してて、どういうことをやると
失望しちゃうのか。 アート・オブ・SLOってワークショップあって、
そこにもあるんですけど、本にも書いてあると思うんですけど。 そこをきちんと見つけて、どういうふうにアプローチしていくかって、
自分たちで考えられる人たちを集めてやることが多いですね。 もしくはそこにちょっと知識とかパワーが足りないっていうところは、
そこを一緒に動かして、一緒に応援して組織を作っていく みたいなことを結構やってますね、今。
自分の会社で言うとSREっていないんですよ。 インフラエンジニアみたいな呼び名なんですけど、
SREっていうキーワードを聞いたときにセットで出てくる言葉が、 さっき竹澤さんもおっしゃいましたけど、SLOっていうキーワードがあるじゃないですか。
SLO、SLIですね。SLAもありますけど。 こやつらは何なんですか?
いい質問ですね。
ネットとかにいっぱいあると思うんですよ。SLO、SLIについて。 ニューレリックとかデータドックとかで計測できるよっていうのがあると思うんですけど、
あれはあくまで、HOWの話なんですよ。 曽大さんとかよく好きだと思いますけどね。
あれはHOWとかの話であって、なんであれをやるかっていうと、 自分たちのユーザーの目線に立ってみたときに、
どういうことが起きたら、何パーセント以上起きたら ユーザーやめちゃうよねっていうところまで落として、
それは可視化するとこの値だよねっていうところをやるんですよ。 あれはモニタリングをバンバンバンバンやって、
とりあえずリクエストレスポンス早いぜ、イエーイ、 みたいなことをやりたいんじゃなくて、
それが意味のあるところと意味のないところってあるんですよね、当然。 それはユーザー側、つまりインタラクションを理解してウェブサイトがどうなってる。
ウェブサイトだけの話じゃないですよ、SLO、SLIっていうのは。 なんですけど、利害関係者の人、使っている方たちがどこがヘイトに溜まるポイントなのか、
ワークショップで言うとアンハッピーなポイントがあるんですけど、 あれをうまく見つけて、そこに行かないようにそのSLIメニューっていうのがいくつかあって、
どういうところを我々は注力して計測するとか、どういう判断をする。 SLOはそのSLIを元にして、SLOはこれです。
これは我々は守らなければいけませんよっていうのを指標にして、 その指標を使って、ここからすごい大事なんですけど、その指標を使って、
その組織のあり方とか、ものづくりの仕方とかを変えていくっていうものなんですよね。 あのSLI、SLOっていうのはそういうのに使うものです。
エラーバジェットはもうちょっとそれがうまく回ってきたら、 どれだけ改善に当てるかっていうのをやればいいんですけど、
急にやりだすと多分あまりうまく進まないんで、みたいなやつですね。
キーワードに引っ張られて、本来やるべき活動じゃないところなんか頑張りそうで。
そうそうそう。だからよく話聞きに行くと、 エンジンXとかでログが取ってるんですよって。
なるほど。じゃあそのログは何を表してるログなのかって話を聞くと、 いやアプリケーションで取れるのはこれなんですよねみたいな話をよくされて、
いや、それをやりたいわけじゃないよね。
APIをいくら早く変えそうが、フロントエンドめちゃくちゃ遅かったら、 それユーザーやめますよね。
じゃあ計測するとこリクエストレスポンスじゃないじゃんみたいな話だった。
そんな感じでインタラクションを全部理解して、 自分たちのユーザーは、ユーザーって言ってもお金を払ってる人払ってない人を 区別も結構するんですけど。
それは事業のドメインによって違うんですけどね。 その人たちがハッピーになるところをどこなのか。
それをきちんと見つけましょうっていう感じ。 そのリクエストレスポンスがどこまで取ってるかバーってもらって、
これはユーザーがどういうところをするときのものに当たるのかみたいな話を結構して、 そこからも煮詰めていくっていうことをよくやってます。
それをひたすら頑張るっていうね。
さっきZoeさんもチームの立ち上げの時に、
SRの方の話をチロッとされたかもしれないですけど、 それは擦り合わせて決めるみたいなことをやったんですよね。
そうですね。相竹さんがおっしゃってるように僕も、 うちも結構複数のプロダクトを扱ってるんですけど、
プロダクトの性質によって重要なメトリクスというか、 そうじゃないメトリクスみたいなのとかが全然違かったりして、
B2Bっぽいやつだとやっぱ記事ページみたいなところの レスポンススピードとかが大事だし、
画像とか出てないとめっちゃ困るんですけど、 一方でB2Bみたいなサービスだと、
サービスのコアみたいなところがもうちょっと違う、 集計した数値とかの信頼性みたいなところが重要になってくるので、
SREの活動とは
集計するロジックの妥当性というかが大事だよねみたいなのを、 各プロダクトごとにちょっとずつ擦り合わせていくみたいなのをやってました。
SRE活動とはみたいなのが本当ふわふわしてて、 本とか記事とか本当たくさんあるけど、
結局会社ごとにやってることは全然違うので、 それによってSRE活動って全く違うじゃないですか。
実際みんなどんなことやってるんだろうなっていうのが気になってて。
相大さんのところにはSREっているんですか?
さっきも言ったけど、 SREっていうロールを置いてるっていうわけじゃないんですけど、
SREが他の会社さんでインフラ面倒みたいなのとか、 自分たちのサービスの信頼を上げる仕事をやっていかないといけないから、
明確にロールはあなたはSREで決めてるわけじゃないけど、 やってる仕事が多分SREって呼ばれるようになって、
仕事をする人とかタスクってのがあって、 興味的にも他の会社でSREやってる人が、
うちの会社に立ち上がってくれてるパターンもあるし、 うちのバックエンドエンジニアの人がそれをやってるパターンもあるけど、
さっきのSLOの話あったんですけど、 サービスを良くしていくっていうのは、
ユーザーが困らないために ここは絶対守りましょうし、
ユーザーさんが喜ぶために こうやっていきましょうと。
あとはプラットフォームエンジニアが、 僕らのこの前の65回でも話題になってて、
チームを良くしていくと最終的にサービスも良くなるし、 サービスを良くするためにここを良くしなきゃいけない。
僕らはSREの文脈として結構やってて、 一番分かりやすいのはデプロイ。
CICD良くしていくとか、テスト早くするとか、
あと、うちだとあるんだけど、 AWSのコストを毎日スラックに投稿して、
スコアが上がってる、下がってるとか、
思ってないところで値段が上がってるから、 これは使い方間違ってるみたいなことも見える化したりとか、
そういう風なところもSREの文脈として やってたりっていうのはありますね。
やっていいっすね。
単純にコストのやつ、良いな。 真似しようかな。
やってないよ。
コストやるな。
月1ぐらいでは見るんですけどね。
グラフにするとめちゃくちゃ良いです。 増えてる時点というかすぐ分かるから。
あとちょっとさっき竹澤さんが、 ちょこっとだけ話したけど、
アートウェアSLをワークショップって、 僕全然知らなかったんですよ。
こんなのあるんですね。
ありますあります。 これ絶対やったほうがいいですよ。
このワークショップやると、 SREって何かっていうのがすごいはっきり分かるんですよ。
これおすすめです。
グーグルのページにそういうスライドとか、 ワークショップの資料が上がってて。
ありますあります。
日本語訳も途中までされてると思うんですけどね。
スピーカーノートついてるんで、 誰でもやろうと思えばやれると思います。
そうなんですか。
自分はそれ結構何回もやってるんで、
よくファシリテーターとして呼ばれてやるんですけど。
なんかテキストみたいなのに沿ってやる感じなんですかね、 この提供されている。
そうですね。
スライドはストーリーというか、 SREって何っていうところから、
SLO SLIとかESLIって何みたいなところを やって掘っていくんですけど。
一通りやった後に実際にゲームの課金ですね。
アプリのゲームの課金の題材を使って、
急にESLIをみんなで選びましょうってやるんですよ。
チームに分かれてインタラクションどうなんだっけとか。
初めて見るやつ。
初めて見る前に一応ハンドブックがあるので、
それを事前に渡して中身を読んでもらったり。
読んでない人向けにも事前に説明するんですけど。
どういうSLIが考えられるかやってもらう感じですね。
それ終わったら答え合わせとかは別にしなくて、
一番大事なのはどこがどういう風になって何が大事なのかって、
チームでディスカッションしてもらって、
それをアウトプットしてもらうことが一番大事なので。
合ってる合ってないは別にあんまどうでもいい。
どうでもよくないですけどね。
真面目にやってるところはちゃんとやりますけど。
そこは重視ではなくて、
どういうコミュニケーションをしてどういうことを考えてたか
っていうのがやっぱりすごい大事にしてる。
SREの哲学
それが終わったら回答例がですね。
SLIが4個ぐらいかな。
作れるんですけど。
頑張れば4、5個ぐらいいけるのかな。
5個ぐらい多分いけると思いますけど。
4つぐらい回答例があって、
それをザーッと説明して。
で、体験してもらうって感じですね。
そこから先は、
うちでもぜひやりたいって言われたら、
本社のサービスのどういうとこからやるか、
まずもドメイン全部教えてくれ。
そこから大事なとこから、
ここやりましょうとバーッと入ってくるんですけど。
それでやるとみんな結構わかって、
ついてくるって感じですね。
いきなりやっぱりメトリクスだみたいなことを
やってるところはうまくいかないので、
そうじゃなくてまずこっちやろう。
それを経験してもらうとみんな、
全然違ったんですねって。
結構評判いいんですよ。
やっぱりやると。
みたいなやつです。
これ初めて知ったので、
こんなのあるんだと思って。
おすすめです。
でも多分長く経験してるエンジニアから見ると、
当たり前のことじゃね?って
多分思うと思うんですけどね。
ありがとうございます。
そうですね。
総代さん先ほど、
SREはゴールじゃないみたいな話を
してましたけど、
この哲学って書いてるのは
どういうことですか?
いや、SRE本っていうのもそうだし、
SREの探求っていう
続編みたいな、
フォライディーの暑い方もそうだし、
あれどっちも、
SREっていうEって、
SREのサービスリライアビティエンジニアリンクなんですよ。
人のことを指してるわけじゃなくて、
エンジニアのことを指してるわけで、
振る舞いなんですよね。
だからこういうふうなサービスの作り方をやっていこう、
僕たちが良いことをやってみて、
こういうふうな考え方で、
だからこういうことをやりましたよ、
そういう振る舞いって、
どういうところで決まっていくかって、
自分の考えている課題だったりとか、
思いみたいなものを具現化していくためなんですよ、
わけじゃなくて、
それって中心にあるのは、
哲学だと思って、
だからSREって言ってるけど、
SREは自分がどういうふうに
ソフトウェアエンジニアとして
サービスに貢献するかという哲学のことを
チームの改善
まとめてあるものだなって思う。
これが他のロールでも、
CREだとCustomer Reliability Engineering、
これは顧客と向き合うために
どうソフトウェアを提供するかとか、
ソフトウェアを通じてどう顧客と向き合うか
という考え方だと思うし、
DBREだとデータベース、
データをどうユーザーに届けるか、
守るか、チームで活用するか、
そういう考え方がたくさんあって、
そういうのをたくさん学んだりとか、
自分のものにして、
エンジニアとして成長していくとか、
価値のあるサービスを提供できるようになっていく
エンジニアに、
振る舞いが追いついていくってことかなって思う。
僕最近、
インフラ寄りの書籍を何冊か読んだんですけど、
技術のことももちろん書いてあるんですけど、
結構人間性みたいなことが書いてあって、
それ答えないやつじゃなくて、
割と何冊読んでも書いてあるんですよ。
いい人になれみたいなのが書いてあって、
いいフレーバー寄せようみたいな。
特に、
そもそもソフトウェアエンジニアって、
生の本番のソースコードに近いところで
回ってるから、
センシティブな情報を見れたいとか、
データベースの中身を見れたいとか、
バグを出したらそれだけでたくさんのユーザーに
迷惑かけちゃうとか、
すげえ権威的なんですよね。
力がある。
特にその中でもインフラって、
より権威的だから、
逃げ恥のシーンで、
この会社の命運は俺らが握っている、
このクソインフラエンジニアめ、
みたいなことを言われるシーンがあるんですけど、
あれとかって、
あのシーン自体は笑い者になる。
でも実際そうで、
インフラエンジニアが本気を出したら、
その内緒が起こせるわけなんですよ。
だから、
そういう意味では、
人間性ってめちゃくちゃ大事だなと。
うん。
確かに。
それぐらいの操作ができますもんね。
そうそうそう。
悪意持ってVPCごと削除するとかできますからね。
笑
そんなことやらないけど。
笑
怖いけど。
そんな関係を持っている。
笑
確かにな。
あとあれです。逆に、
インフラエンジニアに限らず、
エンジニア全体そうなんですけど、
僕ら一人でできることだけが知ってるから、
みんなに手伝ってもらいながらやっていかなきゃ。
それって、
嫌な奴のことは手伝ってくれないし、
伝わらないから。
だから、
良い人で歩くことってインフラエンジニアに
めちゃくちゃ大事だし、
他の事業部だったりとか、
コミュニケーションするってインフラ多いから、
やっぱ大事なんで。
そういう意味では、赤瀬さんは向いてるなって思いますよ。
笑
怒られた。ありがとう。
笑
でも武田さんまさにそういうことを、
記事に書いてましたもんね。
そうですね。
そうですね。
しっかりまとめられてて。
めっちゃ読みましたよ、あの記事。
ありがとうございます。
うなずきながら本当に読みました。
笑
そうなんですよね。
最近思うのは、
アプリケーションエンジニアとか、
インフラエンジニアって、
明確じゃないけど、
千引きをだいたいするじゃないですか。
いらないんじゃないのかって、
最近すごい思っていて。
なんでかっていうと、
クラウドとかがやっぱり多くなっている中で、
アプリケーションだけど、
クラウドは触れないっていうことは、
絶対あり得ないじゃないですか。
コンテナ使うんだったら、
ネットワークは分かってて当たり前だしとか、
Kubernetesやるんだったら、
自分たちネットワークをちゃんと設計できないと、
使えないわけですから。
それが、たとえば分からんから、
インフラエンジニアお願いっていうのは、
間違ってると思って、ずっと思ってるんですよ。
何年もそうなんですけど。
SREっていう考え方っていう活動とかの話になると、
それはもう通り越して、
きちんと向き合うものは、
今持ってるものじゃなくて、
向かいにいるユーザーだから、
そこに行くためには何でもしないといけないですよね。
それがチームをよくするんだったら、
CICDから始まるしとか、
それが、たとえばPDMと
仲が悪いとこがいるんだったら、
そこに入って、
エンジニアリングの専門性とサイロ化
それは良くないですよみたいなところに入らないといけないし、
何でもしないといけないわけですよ。
それがアプリケーションエンジニア、
インフラエンジニア、
日本って特にそうかなと思うんですけど、
引いた上で、
立ち向かうっていうか、
そこからSREとしてやっていくぞっていうのは、
ちょっとハードル高いようになってすごい思うんですよ。
だから、
じゃなくて、そもそもアプリケーションエンジニア、
インフラエンジニアっていう考え方すら
やめたほうがいいと。
もうなんか、
DevOpsって言ってる時点で、
負けてるんじゃないかと僕は思っていて。
いや、そうそう。
そんな気がするんですよね。
そうそう、そうなんですよ。
そうなんですよ。
そういう概念すら、
なんかもう、
いいじゃん、みんなでやろうよみたいな。
そうそう、そうなんですよね。
いや、もうまさにそうですよ。
だってCICD他の人に作ってもらうって
ありえないですよ、普通は。
自分で作ったもん、自分で動かすやつって話ですから。
それはなんか、分かりますね。
うん。
極端な話ですけどね。
新しいロールが出てくると、
みんなそれになりたがるんだけど、
格好よく見えたりもするし、
気をつけたりもするんですけど、
結局それって、
よく本に書いてある、
サイロ化を起こす原因なのでは?
って思ってまして。
結局分断を生んでるんじゃないかな
っていう気はちょっとしますね。
なんかその、
今のエンジニアリングの
こういう界隈って結構
明確な、明確なっていうか
狭めようとする
動きというか、
専門性大事みたいなところ
結構多いじゃないですか、今だと。
だからそれも、
本当に良いようであんまり良くないんじゃないかな
とは思っていて、もちろん専門性って大事なので、
一般のウェブアプリケーションの人が
いきなり機械学習の論文を書けてたらできないんで、
それはある程度は仕方ないとは思うんですけど、
なんかそれがいきすぎるとやっぱり
サイロ化が起きてしまうんで、
サイロ化が起きるとやっぱり組織もサイロ化になっちゃうしとか、
自分はデータ周りとかに入ることがよく多いんで、
なんか営業チームとアプリケーション側の
見てるデータが違うとか
よくあるんで。
でもやっぱそれって
活動の幅を狭めるからこそ
余計起きちゃうんですよね。
SREチームの活動と苦労
だからなんかこう今の世の中
良いのかなって。
もうチャットGPTとかがあるんで
楽できる分、なんかもうちょっと
緩くなってくんないかなって思ってますよね。
Zoeさんが2021年から
立ち上げて
もう2年経つわけじゃないですか。
その中で
そういうチームを立ち上げた
活動の中で
苦労してきたこととか
こういうとこが
難しかったとか、
そういったところってありますか?
苦労したので言うと
やっぱ
さっき東大さんとかが言ってたような
SREの哲学というか
我々のサービスを
どう良くしていくのか
みたいな活動を
開発チームに浸透させる
活動みたいなところは
結構最初は苦労
で
どうやって良くしていくんだっけ
みたいなのを
今までは球体維線のやり方で
やってきてみたいな
ところだったんで
本当はもっとこういう風にした方が
良いんだよみたいなのを
一緒にやっていくぞ
っていうのが最初は苦労したところ
でしたね
最初にそれを
話したのと
あと
地道な改善活動みたいなのをやっていって
実際それで
すごい助かるわみたいな
感触というか
確かにこれやった方が良いわみたいなのが
出てきてからは
やっていこうみたいなところになって
ライブラリアップデートとかも
ちゃんと定期的にやらないといけないわとか
CIDとかも改善しないといけないわ
みたいな感じになってきて
でもチームだけで今までやってきて
なかったんで
単独のチームないだけだと
難しいっていうところも
あるのでSRHMが
お手伝いしながら一緒にやりますよ
みたいな感じで
最初は動いていった
2年経って
軌道に乗りつつある感じですか
そうですね
徐々にですかね
まだ結構
いろんな部分が
技術的際じゃないですけど
あったりとかして
まだチームだけの力でやるには
パワーが足りないというか
みたいなところがあるので
そこをもうちょっと
起こそうというか
できたらもうちょい
独力で
走っていける状態になるんじゃないかな
という風に思ってる
そのチームって
インフラとアプリケーションの関係性
何人ぐらいで構成されてるんですか
SREチームは
兼任メンバーで
だいたい構成されてるんですけど
今
チームメンバーは3人
2人と
業務委託1人って感じで
やっていて
そこのリーダーを僕も兼任して
合計4人って感じ
なるほど
インフラな
インフラ大変ですよね
運動していくの
確かにめちゃくちゃ大変ですけど
僕らさっきの
専門性の話は確かになと思うし
人育てる大変さなんですけど
若い子逆にインフラ
触る機会がすげー減ってるから
大変そうだなとは思いますよね
それねたびたび
話してるんですよそれ
どうして
いく方がいいのか
っていうのと
そもそも若手の人が
やりたいのかっていう面もあるし
やらせた方が
いいのかっていうのもあるし
いろいろ難しいなと思っていて
確かにそれで言うと
例えば
僕らってメモリとかも
CPU抽象化された言語しか書いてないじゃないですか
なんなら
PHPとかそうだし
Javaとか書いてると
実行環境あんま意識しなくて
Java自体は動くから
これって抽象化されてるって話だと思うんですけど
インフラが
クラウドによって抽象化されたり
コンテナによって
プロセスが抽象化されて
アプリケーションを置くだけで
抽象化されていくこと自体はいいんですけど
どっかのタイミングで
漏れるある抽象化とか
そもそも抽象化自体をメンテナンスしなきゃいけない
タイミング
知ってるかどうかって大事で
どこまで
僕らがアセンブラを勉強するかとか
C勉強するかみたいな話に近くて
結構全員が
やらなくてもいいと思うんですけど
誰かがやらないといけないから
差し掛けが難しいなとは思います
そうそうそうそう
全員じゃなくてそうなんだよな
全員じゃなくてはいいんだけど
トラブル発生時に
誰かがやらないといけないわけじゃないですか
そうそうそうそう
その時に
誰が触れるかっていうと
誰も分かりませんだと辛いし
ってのもあるんですよね
分かんないと想像できないですしね
トラブルシューティングの時は
めちゃくちゃ出ますねインフラの時し
絶対そうだと思うんですよね
ありますね
障害
障害はもうまさに
まさにそうですよね
パケットの奥まで来とんねん
みたいな話ですよね
そうそうそうあります
でも
あれじゃないですか最近とかだと
いや分かんないです
皆さんの周りは分かんないですけど
自分の周りとか観測してるとこはやっぱり
今だとアプリケーションの作り方だと
イベントソーシングCQRして結構
キーワード出てくるとこが多いかな
と思うんですけど
あれやるんだったらインフラ知識ないとできないですからね
正直なところ
だからこうhowばっかり
こういうエンドポイント叩きましょうとか
グラフQLを使いましょうっていう
正常系を作ることっていうのは
howだけで知っててもいいですけど
まぐったとデバッグするときは
裏側想像できない
できない
そうそうそうそう
そこだなと
うん
やっぱり避けると
限界値が来ちゃうんですよねすぐ
インフラを避けちゃうとやっぱり
どこでどういう通信とかが行われてるのかを
想像できないと
まじで障害対応できない
そうなんですよね
クラウドを使って新しいサービスが出て
余計システムが分散されると
余計ネットワークとかちゃんと意識しないと
できないですからね
そうそう
アプリケーションの開発が簡単になればなるほど
システム複雑になってるじゃないですか
うんなってますなってます
そこが難しさだよなって思ってるんですよね
まじでトラブったときに本当に分かんないんで
どこの画面のログを見ればいいんだろう
例えばAWSとか
AWS
それは感じますね
困ったら全部クラウドトレイル見て
S3とかクラウドウォッチ探すのめんどくさい
しかもああいうのもちゃんとログを出力する
設定にしとかないとログ出なかったり
それも知っとかないといけないじゃないですか
そこら辺はやっぱりトラブルシューティングして
なんで分からなかったのかというところから
徐々に自分たちでやってもらって
グってこういう風に出さないといけないんだよね
というところから始めてもらうとか
それまさにさっき言った
正常系だけを触っていると
分からないところですよね
そうそう
どうなんでしょうね
SQLはやりたいんですかね
どうなんですかね
だって最近SQL
生SQL書きたくないって人が多いから
みんなやりたいと思う
業務上SQLをよく触る方なので
触りたくないのか
どうやって触るんですか
触ったら
何で触るんですか
SQLは全部ORマッパーです
生SQL書いたら負けみたいなのが結構
ミックスで
違うだろって思うんですけどね
インフラやるっていうことは
やっちゃ負けみたいなこと
自分たちは思わないですけど
もしかするとそういう風に思っていることを
やらないといけないかもしれないですね
SREなんかそうですよ
意識を超えてやっていくことが多いんで
キラキラ大事だと思うので
もっとかっこよく見える何かがあるといいんじゃないですか
すみません適当なこと言いました
キラキラっていうかSREは儲かるっていう
バーケティングすれば
若者はそこでしょ
儲かるのかみたいな
確かに
大事なことですけどね
キラキラも
裾野が広がらないといけないんじゃないかと思う
狭める必要はないと思うので
できる人は増えてほしいなと思いますね
そのかっこよさの話でいうと
SREというか
ログとかインフラの状態とか
アプリケーションがどういうことなのか
理解している人がいると
障害発生時とかにも
特定までの時間とか
解消までの時間が圧倒的に早いんで
それを目前にすると結構かっこいいなって
インフラエンジニアの情報交換とイベントの増加
多分思うと思うんですけど
そういうところとかを
もっと表に出していった方がいいのかもしれないですね
最近はだいぶ
そういうイベントも増えて
事例とか
こういう活動をやってますっていうのが
だいぶ目にすることが多くなったんで
前よりはいいかなと思いますけどね
インフラエンジニアって
表に出てこない人が多いみたいな
イメージだったんで
データセンター行ってるとか
そうそう
そういう時代と比べると
全然今は変わってきたかな
と思いますけどね
誰かが楽に入れてくれてるんだよな
だいぶ
インフラっぽい話できたんですけど
なんかこれ話したりないみたいなところってありますか
インフラと話したと
トラブル対応するにやっぱ
オブザーバービリティとかみんなどうしてるんだろう
あーそうね
どうしてるんですかね
これね
自分も聞きたいですよ
悩ましいなと思って毎回
ツールに頼るしかねえっていうので
みんな多分結構そうかなと思うんですけどね
どういうものを可視化してたり
数値化
取ってたりするんですかね
そこも気になってはいて
まあ冒頭でも話しましたけど
会社でそれぞれ
見るべきポイントが全然違うんで
それによって変わるとは思うんですけど
どういったものを
一般的に数値化した方が
いいのかとか
可視化した方がいいのかみたいなところって
きっとあると思ってはいて
他社さんはどうなんだろうな
と思って
気になるところである
あの話せない内容も
きっとあると思うんですけど
オフザーバビリティは難しいな
と思いますけどね
自分の場合はとにかく
どこで何が起こっているのかわからないことが
すごく多いんで
まずは経路とか全部
わかるようにして
ニューレリック様様って感じですけどね
あとそこに出てこないのは全部自分たちで
構成図書いて
アプリケーション内どうなっているか
ニューレリックまで行って
それでまず
何が起きても大丈夫だように
まず一旦それで
基礎的なところは作って
みたいな感じですよね
細かい数値化とかは
全然やってないです
どこで何が起きているのか
まずわからないからそこからだっていう
うちの場合だと
話で大丈夫なのかな
難しいけど
数値はだいぶ
仕組み化されてますね
あらゆるパターンの
これは今こういうことが起きてそう
みたいなのが
通知されるような仕組みになっていて
当たりがつけられるようになっている
偉いエンジニアが
ちゃんと実装してくれてるんで
通知難しいんですよね
あからさまにやばいやつとかって
多分皆さんもあると思うんですけど
常に遅いとか
そういうやつ絶対あると思うんですけど
直さないといけないし
これはここで恐らくこういうことが起きてる
ってわかってて通知出しても
いわゆる狼少年みたいになっちゃって
みんな見なくなっちゃうんですよ
それが当たり前になって
これがね
ずっと直せないのちょっとなって
ずっと思うんですけど
そこが難しいなと思うんですよね
やってる人がいい人だから
めちゃめちゃ気になってるのかもしれないですけど
他社さんはね
どういう風にやってるんでしょうねって
本当気になる
めちゃめちゃ気になりますこれ
カンフォレンスとか
あったら
直で聞くしかないなとか思って
きっと出せない話も多いんで
綺麗な話ばっかりじゃないですか
表に出るの
こういう話で言われると地道だね
話がすげー多いから
インターネットには出せないですよ
いつかの時に
壮大さんとのび会で
その話をずっとしてた
思いがありますね
めちゃくちゃ盛り上がる
のび会ではめちゃくちゃ盛り上がる
さっきからみんな探りながら
何も喋らないっていう状態が続いている
簡単に言うとまずい話になっちゃいますからね
その通りです
僕はマカレルのエヴァンジリストだから
マカレルの文脈で
いろんな会社さんの
オブザーバビリックとか
いろいろ聞くけど
やっぱ
最初の方でSREの話になる
SLOとか
なんで作るか
監視がそれないと
ここ監視しようと決まらないし
ユーザーさんここ困ってるなって
そこ決まらないし
もうちょっとすげー頑張ったら
インセプションデッキみたいな
ドメイン
これを全部埋めていくと
自分たちのサービスだいたいこういう感じだよね
特性わかって
そのためにはこういう
場所が監視のポイント
パーティーの数とか
必ず新規登録されてるかとか
見なきゃいけないよね
データベースのこのテーブルめちゃくちゃ負荷高いから
見なきゃいけないよね
データベースの構成とかアプリケーション
全部壊せて
ドキュメントを壊せると
出てくるみたいな時代にならない
こないだ
それやってた人いましたね
いるの
そういう
データベースの構成とか
アプリケーション
全部壊して
ドキュメントを壊せると
オブザーバービリティの悩み
出てくるみたいな時代にならない
そういう
いるの
そういう話
これは延長性して
こっそりみんなで共有したいぐらいの
いい話
よし じゃあ
話題を変えますか
沢山できたんで
時間が少なくなってきたんでね
イスコンの話をしましょうかね
出た
みなさん出られたんですか
僕今回参加しなかったんですけど
出ました
みんな出たんですね
どうでしたか
惨敗ですよ
惨敗ですね
みんな顔を消して
どんな問題だったんですか
代表説明すると
YouTubeあるじゃないですか
YouTubeみたいな動画配信サイト
赤瀬さんがVTuberだとして
YouTubeのチャンネルを作りたいと登録すると
赤瀬.ハロハンテックJPみたいな
自分のアカウント名が
ドメイン名になる
ポスト名になる
Yahoo.JP
スラッシュ赤瀬じゃなくて
スラッシュ.Yahoo.JP
アカウントが増えるために
DNSに登録しなきゃいけない
なるほど
これがね
DNSサーバーを
10年ぶりぐらい触るみたいな
立ってるんですよ
これはなかなかみんな触らんでしょう
スコアが上がっていけば上がっていくほど
DNSに
さくらインターネットの風村さんが
作ったDOSが来るんですよ
DNSDOS
なるほど
あれをどう裁くかっていうのは
ボトルネックになる
僕らのチームは爆死します
だいぶ黄色が違いますね
一応普通の
Nプラ1とかもあるんですけど
そこだけだとやっぱ
最終的にスコア
ギリギリ伸びないみたいな感じ
面白い
全然準備しなかったので
そこ全然できなかった
やっぱみんな
DNSに苦しんでた感じなんですか
優勝するチーム
優勝したチームとかめちゃくちゃ若いし
他にもスコア高い人とか
若いはずなのに
DNSサーバー自分で立て直したり
みんな普通にDNSサーバー変更してて
すげーな
DNSサーバーを変更するみたいな
こともやるんだ
登録してない
ドメインっていうかホスト名だったら
DNSサーバー開発大会のエピソード
IPテーブルで
ドロップしちゃうとか結構やってる人とか普通にいて
うん
すごい
和風の設定
自分でするとか
そんな8時間の間で思いつくんだ
そうそうそうそう
マジでおかしい
それはでも
あれだろうな現場力だろうな
鍛えられてるんだろうな
ほんとですよ
面白そう
ちょっと問題見よう
もう公開されてるんで
ほんとですか
見てみます
DNSがクセ者というか
すげーいい問題なんですよ
でもそこ
気づいたのも後半だったんですよ自分は
これもダメだろうと思って
とりあえず
それはDTL全部ゼロだから
少し長くしようって
そっかそっか
ゼロとかなってんだ
毎回問い合わせられるんだな
なるほど
いい問題
いろいろ見たら
もうそれだけじゃなくて
もっといっぱいやらないといけない
DNSにまつわるチューニングみたいなことも
あったわけですね
そうです
あとはもちろん定番の
Nプラス1とか
ありますけどね
絶対に手を入れないといけない
プログラミングの箇所があって
直さないと早くならないんですよねきっと
そうそうそうそう
あと今回面白かったのが
配信中の
投げ線の総額が
スコアになるんですけど
投げ線
しそうな人とか
あとは
長時間配信のほうが投げ線が多いんで
長時間配信の人とか
っていうラベルとかがあって
それをどううまく使って
チューニングじゃないですけど
変えていくかみたいなのも
含まれてて
やっぱスコア上がってるチームとか
それをうまく活用して
そういう人のやつは
早く返してそうじゃない人は
ちょっと緩くレスポンス返すみたいな
こととかもやってる
すごいなって思いました
そこまでは発想が至らなかったなって思って
そうだいさんいつ優勝するの
毎年言ってるじゃん
毎年優勝したいですけどね
僕今年はめちゃくちゃ準備したんですよ
僕だって
PHPカンファレンス
沖縄行って
土曜日じゃないですかね
日曜日
月曜日沖縄で
素振りやってますから
結構早くからやってる
準備した感じは
ありましたもんね
めちゃくちゃ準備して
全く戦えなかったってわけじゃないし
何なら僕らのチームはマインスケールから
素振りに移行してるから
多分他の人たちよりも
手数は多かったと思うんですけど
それでも優勝チームとの
スコアの差が開きすぎてて
優勝チームあれでしたよ
12時過ぎには5万点が
特別賞だったんですよ
5万点出してて
めちゃくちゃ早かったんですよ
5万点出したら
トップ30に入るんですよ
2時間でも
5万点出してる
すげーな
46万とかでしたからね
そうそう優勝スコア
2位にダブルスコアとかでしたよ
2位にダブルスコア
2位にダブルスコア
2位にダブルスコアとかでしたよ
桁が違いすぎて
だから僕ら一応優勝目指してたから
Nプラス地味に直してて
この優勝チームに
絶対勝てないから
飛びどくでもいいからなんとかするぞ
みたいな感じでドロドロして
とにかくキャッシュだ
こわい
毎回イスコン面白いですね
面白いですよ
来年もぜひ
みんなで
2022年のPHPカンファレンスと地方のカンファレンスへの登壇
あれですか
皆さん毎年出てる感じですか
僕は今回久しぶりに
もう一回参加って感じです
自分も
同じく久しぶりに
そうだよね
やるぞって感じで
毎年
爆発しますけど
去年も爆発してた気がする
去年は
新卒のこと2人で出たんですけど
若い人と出たりとか
普段一緒に仕事してない人と
行動書く機会ってなかなかないから
そういうのもやっぱ面白いですよね
お祭りですからね
いいと思います
勉強にもなるし
PHP カンファレンスの沖縄の話が
ちらってましたけど
来年のPHP カンファレンスの話は
しますか
いいですね
福岡の話ですか
福岡っていうか
たくさんあるじゃないですか
来年ありすぎてどうしちゃったの
わかんないです
どうしちゃったのって感じですよ
結構プロポーザルの募集も始まって
終わって
タイムテーブルが出始めた
ところもあるんで
1月が北海道で
2月が関西
3月がペチパー会議で
4月小田原
5月香川
6月福岡です
皆さん出されてますよね
プロポーザル
そっか武田さん出さないって書いてたね
ペチパー会議だけ最後だけ
1個だけ出しましたけど
そろそろ若い人たちに
喋ったほうがいいと思ってるんで
若い人が
地方のカンファレンス
行ってほしいっていうのは
2つ意味があってもちろんね
登壇すると
いろんな人とのコミュニケーションが
ハーブになるから
登壇してほしいな
会社の経費で
行きやすくなるじゃないですか
その枠を奪うのは
よくないな
自分の金で行けって思った
確かに
私は主催側なので
主催的な
話をしたほうがいいのかなとは思うんだけど
せっかく
この1月から6月まで
こんなに機会がたくさんあるので
登壇チャンスがこんなに
生まれてることないと思うんですよ
ぜひこの機会を使ってほしいなと
僕は思って
本当に
本当に
本当に
登壇してほしいなと僕は思っています
PHPの話をしたかったら
どっか頑張って
刺さればいいわけじゃないですか
だからどんどん出していってほしいなと
僕は思います
それこそ北海道落ちたけど
僕同じテーマで大阪受かってるんですよ
場所が違うと
求められるテーマも変わるだろうから
あそこ落ちたからやっぱダメなんだ
じゃなくて
とりあえず応募してみるか
全然いいと思うんですよ
そうですね
最初なんか
これ面白いのかなみたいな
そういうのあると思うんですけどね
それももう全部関係なく
気軽に
本当その通りです
気軽に出してほしいですね
自分が
こんなのって思ってても
それを聞きたい人は意外といるんで
そうなんですよね
今のときたぶん
PHP 5.3とかの話もしても
全然いいと思うんですよ正直なところ
だっていっぱいありますから
5系なんか
8.3が出たばっかりだけど
5はあるよ
そうそうそう
だってたぶん
8とかよりも5のほうがまだ多いんじゃないか
って思いますけどね
多いですよね
現場を見ると多いと思う
あとちょっとイベントの話で言うと
竹澤さんの「クラウドネイティブレイズ東京2023」の話
竹澤さんなんか出られるんですよね
はい来月
クラウドネイティブレイズですね
クラウドネイティブレイズ東京
2023ってやつですかね
有明ですね
どんなこと話されるんですか
えっとですね
これは
今日のテーマにもちょっと絡むやつですけどね
SREと
DREっていうところですね
SREのプラクティス
いろんなプラクティスを使って
データ基盤を作っていくとか
作り方というよりも
作り方はもちろんお話ししますけど
そこにどういうマインドが必要なんだ
どういう取り組みが必要なんだ
そういうのをサポートするには
こういうクラウドのサービスがあるよね
クラウドのサービスの話はおまけぐらいにしないとは思うんですけど
そういう話はする感じですね
これオンラインでもあるのかな
オンライン確かあったと思います
なるほど
ぜひぜひ聞きたい
ぜひお願いします
SREメニューのお話もちょっと
もちろんするのと
あとはデータ基盤とか
データマネジメントみたいなのをするときの
マインドセットというか
思考のお話があるんですよね
クリスプDMってやつがあるんですけど
そこら辺のお話とか
表に見えるものだけは信じないとか
そういうお話もしたりだとか
あとクラウドならではの権限管理とか
こういったものでうまくできるように
SREのメニューによって
どれくらいの速さでデータ基盤の
こういうものが必要なのか
そんな感じの話
まさに今日話したようなことも話されるっぽいので
これをぜひ聞きたいですね
はいはい
興味ある方はぜひ
私有明の会場にいる予定なので
はいありがとうございます
はい
はい
といったところで1時間経ちました
あっても
あってもだった
はい
じゃあ第66回は
この辺で締めさせてもらおうと思います
最後にもう一度
XQ Twitterのハッシュタグについて
お知らせです
ハッシュタグはカタカナで
リクエストお待ちしています
はいということで
今回のつなぎMeFM第66回は
土屋さん 総代さん 武澤さんを
お迎えしてお話させてもらいました
今日はどうもありがとうございました
ありがとうございました
ありがとうございました
