1. TimeTreeラヂオ
  2. TimeTreeのSRE(Site Reliabil..
2022-10-07 26:28

TimeTreeのSRE(Site Reliability Engineering)について聴いてみた #TimeTreeTechTalk

エピソードをシェアする

Share on X Share on Facebook Share on Threads

「TimeTreeラヂオ」はカレンダーシェアアプリTimeTreeを運営する私たちメンバーが、ふだんの仕事に関係することもそうでないことも、だいたい15分でひとつのテーマを話しきるインターネットラジオ番組です。

この放送はTimeTreeエンジニアによるテックなお話をお届けする #TimeTree Tech Talk です。

バックエンドエンジニアmiu(ミウ)を呼んで話しました!

お家の冷え対策/猫といえばmiu/SREチーム発足経緯/AWS構成管理/AWS運用自動化/Slack ChatOps/Slack大事/Slack通知の仕組み/AWSパフォーマンス計測/Aurora MySQL/Datadog/New Relic/猫にごはんタイム/特定時間のスパイク対応/公平なサービス体験/チーム構成/チーム活動の可視化/分散トレーシング/物理的なデータ量上限との戦い

◎TimeTree Company Deck(会社案内資料) https://bit.ly/timetree_company_deck

◎一緒に働く仲間を募集しています!(採用応募ページ) https://bit.ly/3MyqZjE

番組の感想・コメント・ご要望はハッシュタグ #TimeTreeラヂオ でつぶやいてください!

サマリー

今回のエピソードでは、バックエンドエンジニアがSREチームの取り組みやインフラの最新状況について話しています。SREチームはインフラだけでなく、サービス全体を見るチームであり、AWSのテラフォームやラムダ、GitHub Actionsなどの技術を活用しています。さらに、モニタリングとスラックの活用により、サービスのパフォーマンスやアクセス状況を把握し、ユーザーに公平なサービスを提供することを重視しています。

SREチームの立ち上げと活動
どうも、ミュウです。
どうも、ジールです。
どうも、スティーブです。
今日は3人でお送りします、TimeTreeテックトーク。
やがりました。寒いですね。
寒いですね。
寒いですよ、急に。
大丈夫ですか、皆さん。
今日来てくれているミュウとジールは、結構リモートワークが多いですが、
この冷えに対する対策、どんなことをしていますか、お家で仕事中は。
あれですよね、最近は半袖半ズボンをやめましたね。
なんか、そうですね、今着てますね。
なんか、いつも着てなさそうな服着てます。
ちょっと映ってないから、あれかもしれないけど。
ちょっと急激に寒くなったので、上着を羽織るようになりました。
あー、そうですよね。
これちょうど昨日から、すごい温度下がった日に撮ってるんで、
僕もちょっと服装を間違えて、今半袖なんですけど。
半袖でしかも、エアコンとかが全くない部屋にいて、窓際に座ってるんで、
すっげー冷気がすごいあって寒い。
何も対策してません。
ちょっと出さないといけないですね。
ないとね、自宅が冷えるんで気をつけましょう。
僕らも冷えとかには、たぶん体がもろに応える年齢なんで。
そうですね、若くはないですね。
さてさてさてさて、今日はミューをお呼びしてお話ししていくんですが、
ミューがですね、バックエンドエンジニア職種としてはなんですが、
バックエンドエンジニア何人かいるんですけど、
その中でもミューって結構特殊なポジションというか、
会社全体のインフラになっていたりとかするんですけど、
そのミューに最近の取り組みとかですね、
最新の今のインフラ周りの状況とかをお話してもらおうかなと思っております。
まずは簡単にミューから自己紹介をしていただこうかな。
はい、改めましてミューです。よろしくお願いします。
紹介にあった通り、バックエンドエンジニアとして入社してからずっと働いているんですけれども、
最近世の中の流れもあり、SREチームというものを立ち上げて今運営しております。
もともとメインとしてインフラを一任されるという形でやっていたんですけれども、
サービスも拡大してきたりとかいろいろ拡張してきたりとかそういう側面もあり、
インフラというよりはそのサービス全体を見るチームが必要ということになって、
SREチームを立ち上げたという経緯になります。
今は人数は3人でやっているんですけれども、
インフラはもちろんですね、そのサービスの健康状態だったりとか、
ユーザーへの影響などいろいろ調べて改善していったりしているところです。
なるほど、なるほど。
あと猫が大事ですね。
そうですね、大事ですね。
ミューといえば猫。
ミューといえば猫。
そうですね、そういうイメージがありますね。
なんかちょっと話、初っ端からずれちゃうんですけど、
ミューっていうね、うちニックネーム制なんですけど、
ミューっていうニックネームの由来も猫ちゃんなんですよね。
そうですね、以前保護してもうちょっと亡くなってしまったんですが、
その猫の名前を取りました。
今は2代目のシーちゃんと暮らしております。
会議中もたまに映り込んで和むっていう。
よくミューの本体は猫側だみたいなことをよく言いますよね。
そうですね。
本当は猫で狩りの姿みたいな。
ちょっとあまり親気にはしないんですけど。
すいません、すいません。
これじゃあカットしておいていただいて。
SREチーム。
SREあれですよね。
流行りってさっき言ってましたけど、
サイトリライアビリティエンジニアみたいなやつですよね。
そうですそうです。
改善していきましょうみたいな。
改善していきましょうって言うとすごいざっくりしてるけど、
さっき言ってくれましたもんね、
サービスの信頼性っていう、
インフラっていうところに限らないっていうのが結構ポイントですかね。
そうですね、どうしても日本でインフラエンジニアっていうと、
結構インフラに閉じこもっているイメージが強いんですけど、
そういう意味だとSREっていう文化というか考え方が入ってきたのはすごい良かったのかなって思いますね。
実際結構インフラ周りの領域ももちろん担当ではあるけれども、
主眼に置いてるのはさっき言ったような部分だよっていうことなんですよね。
そうですね、インフラの構築運用はもちろんやるんですけれども、
例えば主となるアプリケーションの開発にみんなに力を入れてもらうために、
無駄なところは僕たちが引き受けたりとか、
デプロイ、リリースのスピードを上げたりとか、そういったところも見ていくという形ですね。
なるほど、結構広範囲ですよね。
そうですね。
もともとSREチームを立ち上げた経緯みたいなので言うと、
バックエンドエンジニアとして入ったけど、
そういう部分は切り出してどんどん進めてた方がいいみたいな感じで考えたっていう経緯があるんですか?
はい、もともと私の方でそういったのを全部持ってたんですけど、
会社サービスみたいなものがどんどん拡大していくにつれて、
どうしても一人だとできる範囲というのは限られてくるっていうところで、
チームとして立ち上げて、興味のある方に賛同してもらったという形ですね。
なるほど。
結構今、領域の話とかは割とイメージができてきた感じなんですけど、
技術スタックとツールの活用
実際に使ってる技術というか、どういう方法でそれをやっているのかみたいなことを聞けるといいなと思うんですけど、
例えばAWSとかそういうパブリッククラウドのところは使ってるというのは、
そういうのの構成管理とかも何かでやってるんですよね?
そうですね。うちはテラフォームで基本的にやってますね。
テラフォームでコード化して構成を作っていると。
他にも何か使ってる技術スタックみたいな話で言うと何かを上げていけるものってありますかね?
技術スタック、そうですね。結構運用が重要になってくるんですけど、
そこら辺だと、うちはAWSのラムダを使って、ノードJSだったりパイソンだったりして、
人でやってた部分を自動化するとかはよくやってますね。
あとはCICD周りで言うとGitHub Actionsというのを作って、
コードのデプロイなどの自動化、あとはスラックからのチャットオプスですかね。
そこら辺もやっているという感じです。
結構チャットオプスは割と早めからうちの会社ってやってるイメージでしたよね。
そうですね。僕が入社する前からそれをやってて、スタックを作ったんですかね、ボットを。
それに相乗りする形でサービスの拡張とともにどんどんスキルが追加されていくようなイメージです。
できることを広げていけてる感じですよね。
そうですね。技術スタックとはちょっと違うかもしれないんですけど、
SREというかサービスの状態を知るという観点からいくと、結構モニタリングとかが非常に重要になってくるんですよね。
そこで気づけるようにするための一つのツールとしてやっぱりスラックはすごい重要になってますね。
どんなふうに活用してます?スラックの通知みたいなところは。
そうですね。緊急度の高いものと低いけど覚えておいたほうがいいものっていうのをまず2つメインで分離させて、
今すぐに対応というか状態を確認しなくちゃいけないようなものに関しては常に通知がされるようなチャンネルに通じて、
あとはこれはリファクタリングしたほうがいいよねとか、そういったものの通知に関してはチームのスラックに通知をして、
あとは自動でGitHubの一周に登録するような形を取っています。
なるほど。
GitHubのほうはチケットとして感じてできる人がやっていくみたいな。
じゃあパフォーマンス計測みたいなやつもどこかしらでやってるってわけですよね。
それはどういうの使ってるとか何を見てるみたいなのってどういうのがあったりするんですか?
今はパフォーマンスに関してはAWSの環境だとクラウドシメトリックっていうのがあって、
その他にも今はデータドックっていうのを利用していて、
アプリケーションの内部のパフォーマンスだったりそういったものを見ていて、
メインクラウドはAWSなんですけど、データベースの場合はAuroraのSQLを使っていますが、
パフォーマンスインサイトっていう機能があって、
そのメトリックを取ることができたりして、そこら辺を統合的に監視しているっていうイメージですね。
結構この辺の話題はマジで月以内感じがありますね。
聞けば聞くほど多分本当に後半だから、こういうジャンルだとこういうのを使ってるとかって、
またちょっといろいろ掘り下げる甲斐があってもいいかなと思うんですけど、
結構本当にいっぱいありますもんね。
モニタリングとサービスの公平性
今ちなみにAppdreamというか、アプリケーション周りのデータドックから今、
New Relicをちょっと検討しているようなそんな感じ。
その時に合わせて新しいというか、いい方に移ったりとかも結構やってるってことなんですね。
なるほど。ありがとうございます。
猫にご飯をあげながら話してもいいですか?
猫に?もちろん。
なごむわー。
ちなみに今の聞いてて、スティーブは何か感じるものはありましたか?
僕の分かる範囲で言うと、サービスへのアクセスが瞬間的に高まる時ってあるじゃないですか。
ありますね。
そういう時やっぱりMewが一早くだと思うんですけど、結構スラックでみんなに周知してくれる?
そうですね。
いいのありますよね。
そうですね。
そういったアクセスのスパイク、スパイクってよく言うんですけど、
この辺は本当に入社してからあまり見れてなくて、
どういう時間帯にどういうアクセスの推移があるかみたいなところ、
そこまでまだ見れていないところだったんですよね。
うーん。
あ、ちょっと雑音が入る。
大丈夫です。
大丈夫です。
そのまま鳴りますけど。
時間帯的にご飯の時間で。
そうですね。
そこら辺はMewが入社してから、入社何年前だ?
ちょうどね、ちょうどというか2018年の1月に入社したので、5年くらいですかね。
そうするとサービスが始まって3年目くらいの予約、
Mewが入ってそこら辺を整備し始めていったって感じですね。
そうですね。
うちのサービスTime Treeは特に結構特徴的な、特徴が強い、
アクセスの状況がすごい特徴が強いサービスで、
予定管理ツールなので、みんな結構同じ時間帯に確認するんですよね。
6時半とか、それぞれのライフスタイルにあった人たちが、
同じ時間の切れ目に確認をするっていうのがすごい分かっていて、
その瞬間だけサーバーを増強したりと。
結構あれですよね、細かく調整しないといけないんですよね、本当に。
そうなんだ。
よくパブリッククラウドってオートスケールみたいな仕組みがもちろんあって、
勝手にやってくれるみたいなので任せがちなんですけど、
Mewが減ってくれてるような特定の時間に対する急激なスパイクみたいな話っていうのは、
完全には対応できないんですよ。
間に合わないですね。
増強するのもラグがちょっと出ちゃうじゃないですか、どうしても。
だからちゃんとこの時間ぐらいから始めるみたいなことをやってないといけないんですよね。
それをすごくこのMew、はじめSREチームとかが見て調整をしてくれてるから、
うまくアクセスが滞りなくやってるっていう、できてるって感じなんですよね。
一応僕が入って大事にしているところっていうのが、
ユーザー全員が公平なサービスを受けられるっていうのがすごい大事なんですよね。
重要視されていて、
日本でもそうですし海外でもそうですし、
同じ使い心地、同じUXを体験してほしいっていうのが僕の中であるんですね。
クライアントアプリケーションがうまくできていて、それが全世界に配布されたとしても、
サーバーサイド側が遅かったりとか、ある特定の時間が遅かったりすると、
その使った状況によってユーザーの体験ってすごい変わってしまうので、
SREチームの活動
こうなるべく差分が出ないような状況を作り出したいっていうのが目標としてありますね。
なのでその時間単位で増強したり、
あとはその海外からのアクセスもなるべくレイテンシーが少ないようにしたりとか、
そういったところを目指しています。
なるほど。確かにあれですよね。
ISPとかだとこの時間めっちゃ混むみたいな、
遅くなるみたいなのって結構よく聞きますけど、
そういうのは絶対ないようにというか、
ちゃんといつでもアクセスが滑らかにできるみたいな、
それが特に世界中でも影響がそんななくできるようにしたいっていうのがすごいあるってことなんですよね。
はい。
素晴らしい。
MU以外のメンバーとかも含めて、
どういう感じでSRチーム活動しているんだろうとか、
どんな感じの雰囲気なんだろうみたいなのを聞ければいいなと思ってるんですけど、
どんな感じでいつもチーム活動っていうんですかね、してるんですか?
チームとしての活動って意味だと週に1回定例を行っていて、
ちょっと猫が暴れながらなんで。
画面の向こう側がバタついてる。
定例の中でチームを立ち上げて間もないっていうところもあって、
すごい有名なSREの本があるんですけれども、
それの輪読会を1時間ぐらい、
あとは週にやったことの共有ですとか、
あとはパブリッククラウドだったり技術的なフィーチャーみたいな、
ちょっと気になった部分っていうのを共有したりとかしてますね。
どんな感じのメンバーがいるんですか?
MUはもうすぐ5年とかになるっていう感じでしたけど、
他のメンバーも近いんですか?
SRチームの活動形態とメンバー
そうですね。
一人は入社されて3年ぐらいのGREGっていうメンバーがいるんですけど、
GREGは今もバックエンドをメインとして働いてはいるんですが、
SREにすごい興味があるということで参画してもらって一緒にやってます。
もう一人はロッキーと言って、
この方はいつだっけな、
今年の3月なのでまだ入って半年?
最近ですね。
かつフルリモートで九州の方ですよね。
そう、福岡ですね。
福岡ですね。
働いてます。
もともと別の会社さんでもインフラメインで、
結構全体的に見てた方で一緒にやってもらってるって感じですね。
なるほど、なるほど。
じゃあ結構MUがフル株、一番フル株で、
間にいて最近の人もいるみたいな、結構バランスが。
確かにそうですね。
割といろいろ言ってMUがいろいろ言っていきながら、
みんなもそうだね、あだねみたいな感じの進み方なんですかね。
そうですね、基本的にはそうなってますね。
ただそのトップダウン的なやり方はもちろんやりたくないので、
みんなで意見を出し合って回せるような仕組みというか環境作りというのは心がけています。
なるほど、なるほど。
やっぱり課題とかこういうところ結構注目だよねみたいな話はやっぱり、
昔からいるエンジニアだったり、
特に立ち上げた感度が一番高いっていうのもあるのかもしれないですけど、
そういうところから出やすいってことはあるんでしょうね。
とはいえみんなでちゃんと議論できるような感じでやってると思うんですね。
そうですね、その感度的な部分というと、
グレックはもともとRubyがめちゃくちゃ強いっていうので、
そういうところなんですけど、
ロッキーとかも結構インプットが好きな人間を読んでるので、
結構みんなに刺激があるような会話っていうのができたという気がします。
すごい良いですね。
皆さんがインプットしあって出し合ってる関係性なんですね。
最近ですかね、特にこのSRチームでここら辺に注力してやってるみたいなところとかが、
もしあればその辺ちょっと教えていただければと思うんですけど、
どんなところがあってします?
注力、そうですね。
メンバー的な部分でいうと、やっぱりロッキーがまだ入ってて日が浅いので、
なるべくサービス、チームに密着した形で関わってほしいっていうのもあるので、
みんなと、特にフルリモートっていう福岡ってちょっと離れているっていう物理的な機能もあるので、
会社のメンバーとチームとサービスに早く慣れてほしいというところがあって、
そういうふうに働いてもらっているっていうのが一つ注力している部分ですね。
もう一つ、技術的なところとかでいうと、やっぱりスタートアップというところもあって、
サービスの展開だったり新規だったり、いろいろスピード感を持ってやっていかなくちゃいけないというところもあるので、
インフラとかに関してもドライをなくして共有していく部分を増やしていこうというのは強く期していますね。
結構いろいろやっていることとかの共有だったり、知見とかですかね、
みたいなところはあまりクローズドにせず、いろいろ出しているっていうところを気をつけているって感じなんですね。
そうですね。あとはドキュメントにもっと落とし込むことももちろんなんですけど、
ソースコードに落とし込んだりとかっていうのも意識しています。
そうですね。僕は結構意識してますね。やっぱりやることが多いのですぐ忘れてしまう。
チーム用のタスク一覧みたいなところにとりあえず思いついたら書いて、
やっぱりその後優先順位だったり重要度を考えてやっていくっていうのを心がけてますね。
結構SRチームのタスク管理、すごいきっちりやってるなっていう感じの印象を持ってますね。
なんかボードとかをしっかり作ってる感じですよね。
GitHubで管理できると良かったのかもしれないんですけど、
全社で見れた方がいいと思ったりとか、
あとはSREの場合、プロダクトをかなり全社に影響するところが非常に多いので、
ノーション使って管理してますね。
ノーション、はい。ノーション全員、今会社全体で使ってますし、そこでやってるんですね。
あとそうですね、割と今のは組織的な意味合いでの課題というか、
注力ポイントみたいなのを答えていただいたんですけど、
施策的にやってることみたいなのって、今何か言えることであったりするんですか?
そうですね、パフォーマンス、モニタリングの意味だと、
今まだ分散トレーシングっていって、
クライアントからバックエンドまで通管した監視っていうのがまだできてないので、
そこらへんのリリックをテスト導入してみて、できるかどうかっていうのを試している最中です。
アプリケーションが直面している問題っていうと、バックエンドですね。
バックエンドのデータ量が非常に多くなってきていて、
物理的な上限っていうのもそろそろ近づいてきているというところなので、
データベースをシャーディングして、半永久的な可能状態を作る、
継続状態を作るっていうのを取り組んでいるところ。
そうですよね。データ量が本当に、タイムツリーって今めちゃくちゃ多い。
毎月というか、毎日どんどんデータが入ってくるっていうのをとにかく溜めているから、
何するにしても時間がかかるようになっちゃうみたいな話とかもありますよね。
データ整形をするにしても、1ヶ月、2ヶ月とか普通にかかるとか。
結構そういう風になってきているというのは、割と課題として大きくなってきているということなんですね。
単純にその容量、先ほど言っていたような、これぐらいしか扱えないみたいなところが
うまく扱えるように分散しておくみたいな話とかいますので。
今回はMiuをお招きして、簡単にではありますけど、いろいろチームのこと、
今取り組んでいるSREチームのことについてお話しいただきますが、
今日の出てきた話題はまた今後も掘り下げていっても面白そうですが、
最後に15秒のお時間がPR枠がありまして、そこで採用PRができるというですね。
今絶賛、バックエンド系のエンジニアの人たちって絶賛絶賛大大大大募集中だと思うので、
Miuからぜひメッセージをいただけると嬉しいです。
Time3のSREは日本だけではなく、世界をまたいだサービスを支えているチームになります。
もちろんやることもたくさんありますし、刺激的な気になるようなところもいろいろやってますので、
SREインフラだけではなく、もちろんアプリケーションの技術を持った方でも全然活躍していただけると思いますので、
興味のある方はぜひ応募ください。よろしくお願いします。
あと特典としては、Miuからおいしいラーメンの作り方を教えてもらえる。
ラーメンの作り方と、あと定期的に猫の写真を贈呈することもあります。
いい特典。じゃあ今日はMiuをお招きしてお話いただきました。ありがとうございます。
はい、ありがとうございました。
ありがとうございました。
26:28

コメント

スクロール