目次
1.イベント概要
2.登壇内容と感想
3.懇親会
4.全体のまとめ
1.イベント概要
SRE NEXTとJAWS-UG TOHOKUの2つのコミュニティによる合同のイベント。昨年も開催されたらしく合同での開催は今年で2回目？らしいです。あくまで参加者側としての推測になりますが、SREという考えの普及を促しつつ、互いに関係を築くためのイベントなのかと…
SRE（サイト信頼性エンジニアリング）とは、信頼性の高い本番環境システムを実行するための職務、マインドセット、エンジニアリング手法のセットとのことで、Googleから提唱されたとのことです。
※SRE NEXTのイメージキャラ
名前忘れちゃいましたが、ペンギンとカエルを合わせたものらしいです。
2.登壇内容と感想
全ての登壇内容をご紹介・触れることはしておりません。記事を書きやすいものや個人的に触れたいものをピックアップしていることをご承知ください。
大規模組織での障害対応：楽天エンジニアの切り分け術
※登壇資料が会社の承認が降りてないらしく、撮影NGのため写真はありません。
実際の障害とその流れ
サービスの中で一部APIがタイムアウトしているという障害が発生。
監視体制：ログやメトリクスを集約し、その監視を外部サービスに委託しているとのこと。
初動で確認できた点（明言されていませんでしたがおそらく初動）：DBのメトリクスなどは正常。POD単位確認した限り原因ははっきりわからなかった。
調査：エラー内容の把握、ステータスコードから原因推測、エラー発生箇所をレイヤー構造で特定、特定APIごとでの調査（例、OPenAIのAPIであれば、公式から障害発生の情報がでていないかやエラーコードのドキュメント確認など）
原因：特定のPOD実行時のCPU使用率が99％だった。
解決方法：再起動
障害対応を行う上でのハードル
1、システムの複雑性
マイクロサービス、レガシーシステムとの連携
2、組織の複雑性
グローバル展開による言語差や時差の格差、組織が大きいことによる情報伝達の遅延発生
感想
グローバル化によって情報連携や対応の遅延が発生するのは楽天やその他大企業ならではと感じました。
※当事者になったらそんなこと言えないですが、そんな苦労をしてみたいものです。
個人的には、原因特定ができた流れを知りたかったので、その辺りを深掘りしてもらえると嬉しかったです。
しかし、DBのメトリクスは収集しているのに、その項目にCPU使用率は入ってなかったのかが疑問に感じました。システム構成図を表示していただいた限りAWSを使用していたので、基本的に監視している項目ではと感じました。
IVRyの組織の形とSLO運用の現状
お恥ずかしながら今回のイベント参加時点でSREという概念自体知らなかったため、社内でSREを推進する活動についてはあまり触れることはできません。
こちらは翌日の3月30日時点で資料がUPされていましたので、以下URLよりご確認ください。
https://speakerdeck.com/abnoumaru/ivrynozu-zhi-noxing-tosloyun-yong-noxian-zhuang
※開始！
※IVRyはどんな会社なのか紹介
ふむふむ、音声データのAI活用をされていると。個人的な話ですが、もとテレアポ営業マンかつ音声データからのデータ登録処理を個人開発で取り組んでいるのでとても興味がわきました。
※プロジェクト間を横断するSRE組織があるとのこと
※SLOのドキュメント
SREにSLO？この時点でサービス評価のためのSREという概念にSLOという項目のあるのかな〜以上の内容がわかりませんでした。
感想
おそらく登壇されている方にとっては、SREがメインであり、事業のAIを活用した電話サービス構築の話はサブ程度だったのだと思います。個人的にはそちらの方に興味津々でした。
※まだまだ視座が低くて… 組織開発などはあまり興味を持てなくて申し訳ないです。
音声データやテキストデータなどの非構造化データを構造化データに変換するのにLLMが適しているという話もっと聞きたかったです。コンピュータが読める形に落とし込む上での、工夫や注意点を知りたかった。😢
Re:Starting SRE 〜 KTC SRE が SRE として活動するために必要な X のこと 〜
※SREと似たような概念の差異？
SREの概念の説明やその他の似たような概念との違いの説明とても助かりました。おかげて、前の登壇も含めて話している内容の理解が進みました。🙏
感想
先の登壇者の方がメンバー視点でのSRE推進だとすると、こちらの方はマネージャー視点でのSRE推進を話されているのかなと感じました。
また、SREの評価のためのオブザーバーツールとしてNew RelicかDatadocの2つが一般的らしいのですが、導入のための費用がかなりかかるそうです。その導入費用のために上層部を説得したという話をされており、熱心な方が上にいてもらえるのはメンバーとしては助かるだろうなと感じました。
やはり上が動かないと始まらないですよね
インフラ構築での失敗談？（すみません、タイトル確認し忘れました）
※IaCツールごとの特徴
※失敗した時のディクレトリ構造
Iacのことはさっぱりですが、解説いただいた通り、共通部分にここのアカウントごとの情報を入れているので、複数の環境に導入すると、冗長化してしまいますね。
勉強になりました！
インフラエンジニアでは、ディクレトリ構造などはあまり考慮する機会も多くないとのことで、最初は気づくのに苦労したと。
感想
個人開発でIacもやっていこうと考えており、どのツールを使用するか検討していたので、「今後学習していくならTerraformがおすすめ」というお話はとても助かりました。
※構造化の部分でTerraformの方が色々と調整しやすいとのことです。
現役のAWSエンジニアかつインフラ担当として業務に取り組まれている方からのアドバイスなので、ぜひ参考にしたいと思います。
3.懇親会
イベントに参加されていた方のほとんどが懇親会に参加されていました。
色々な方からお話を聞く中で、個人的にとても学びとなった点は以下の2点です。
①同じプロンプト、ナレッジベースを使用しても使用するモデルによって異なる回答がでるという点。
※実際に生成AIサービスを業務として構築されている方からのお話です。
②カスタマー対応などの分野では、AIからの回答の精度の評価は結局人力になってしまうという点です。
※データ分析のように数値が出るわけではないので評価が難しいそうです。
また、同年代の方とエンジニアとしてのキャリアの話をしたりととても刺激をいただきました。
4.全体のまとめ
登壇内容のほとんどがSREという初めて知る概念の内容でしたが、色々なお話を聞くことができました。
思わずして新しい知見を学ぶことができ、こうした点がイベント参加のメリットだと実感しました。
他の記事でも書きましたが、イベント内で技術などの深い話をする時間はほとんどないため懇親会の参加はかなりおすすめです。
また、イベント参加自体はこれで3回目ですが、2回目参加した際に同席させていただいた方より「前回も参加されていましたよね？」と懇親会でお声がけいただけました！←本当に嬉しかったです。目立つような髪型にしていてよかった！
仙台に現在住んでいますので、5月の会津も参加しようと思います。
※確かゴールデンウィーク直後くらい？
ここまで閲覧ありがとうございました！