[レポート]Road to SRE NEXT 2024@福岡に参加してきた #srenext

2024.05.28

SRE NEXT 2024について

信頼性に関するプラクティスに深い関心を持つエンジニアのためのカンファレンス「SRE NEXT 2024」が2024年8月3日〜4日の2日間にわたってAbema Towersで開催されます。

この「SRE NEXT」のプレイベントとして、仙台、京都、広島など日本全国各地で「Road to SRE NEXT」が予定されており、5月24日(金)に福岡@GMOペパボで初回イベントが開催されました。

地元開催ということで参加してきたので、簡単にレポートします。

SRE NEXTオーガナイザーの @shotaTsuge さんと @ryuichi_1208 さんの挨拶からイベントは始まりました。

セッションは幅広いテーマを扱っています

  • マルチプレイ用ゲームサーバーサービスの立ち上げとこれから @takumakume
  • はてなのSRE組織2024 @cohalz
  • LT1: 意義から考える Observability 入門 @stefafafan
  • LT2: SREがいない”今いる場所”で「SRE」について聞いて、考えてみた @maimyyym
  • LT3: 「めんどくさい」をそのままにしない @cd_sioremon

イベント後は、地方ならではというか、参加者の約半数が懇親会に参加し、他愛もない話をしながら、SREというロールに限らず、どのエンジニア組織も同じような課題を抱えていることを感じられたのが、一番の学びでした。

AWS事業部に所属し、AWSを中心とした技術支援(≠SRE)を中心としたクライアントワークが日常業務という立場から、次の2つのメイントークについて簡単にレポートします。

  • @takumakume さんによる爆速新規サービスの立ち上げ
  • @cohalz さんによるSRE(あるいはエンジニア)組織の拡大

マルチプレイ用ゲームサーバーサービスの立ち上げとこれから

最初のトークは、会場を提供いただいたGMOペパボの @takumakume さんによる「マルチプレイ用ゲームサーバーサービスの立ち上げとこれから」です。

パルワールドのようなオンラインゲームの専用サーバーを簡単に構築できる「LOLIPOP for Gamers」を爆速で立ち上げた奮闘記です。

2024年2月9日にプロジェクトが発足した後、わずか13営業日後の2月29日には無料モニターを提供開始し、4月15日には正式版をリリ ースしています。

将来の規模を見据えつつ、スモールスタートかつスピード重視、当然ながらTCOも考慮しないといけないというバランスが難しい制約がある中で、十分な検討時間が与えられていたわけではないにもかかわらず、初期の技術選定が的確で、正式版リリース後も基本構成が変わっていないのはなかなかできることではありません。

SRE観点では、CIのやりやすさやソースコード全体の視認性向上のためにモノレポを採用し、APIにはスキーマ駆動なProtocol Buffers *1およびgRPC/gRPC-Web/Connectプロトコルをまるっと提供してくれて構成がシンプルになる Connect が採用されています。

ゲームサーバインフラ基盤は円安のために割高な海外産パブリッククラウドではなくデータセンターが選ばれています。海外のパブリッククラウド上の安定稼働なインフラも円安のために利用費が増加しており、外部要因とはいえ、コスト削減の強いインセンティブが働いています。

この他にも、分散ストレージのCephを使ったり、リソースのオーケストレーターにはコンテナとVMの両方に対応し、コントロールプレーンも含めた導入が簡単なCanonicalのLXDを採用したりと、技術的にも攻めています。

PMFの試行錯誤では、ユーザーに自由度の高い環境を与えるのか、ゲームがプレイできてカスタマイズする余地があれば十分なのかといった観点も発生し、どちらに寄せるかによって適切なゲームインスタンス環境も変わってきます。前者はVPSであり、後者は複数のアプリケーションから構成される環境をシステムコンテナとしてまるっと軽量に提供できるLXDが向いています *2

Linuxカーネルのバグにより新しいハードウェアのIntel NICで通信障害が起きていたという話なども、パブリッククラウド民はなかなかお目にかかれない、新鮮な体験共有です。

はてなのSRE組織2024

2つ目のトークは、前日のMackerel福岡イベントに合わせて多くの社員が参加していたはてなから @cohalz さんによる発表です。

はてなのSRE組織2024 / Road to SRE NEXT@福岡 - Speaker Deck

DevとOpsが分かれていたインフラチーム時代からSREという職種の誕生、全社展開、SLI/SLO運用の開始、ジュニアSREの採用など、SREが少しずつ広まっていく歴史の変遷が語られました。

プロダクトが使っている一般的な技術の他にも、部門固有の技術、コードを書く能力、クラウド、セキュリティ、独立度の高いベクトル、習得にどれも時間のかかる能力が求められます。

障害対応一つとっても、よく起こる局所的で単純な障害ならまだしも、多くの障害は複数の要因が絡み合っており、システムが複雑化している現代では、絞り込みを行うだけでもそれなりの経験を要します。アーキテクチャの改善を検討する場合も、全体を俯瞰しながら要所を押さえる能力が求められ、一朝一夕に身につくものではありません。

組織としても、知見の共有、標準化、ジュニアの育成など、ゆっくりじわじわと進歩するものです。新しい施策は理解しやすく良い結果を伴わないと、広げづらいという側面もあります。

結局のところ、SREロールに限定せず、エンジニア組織、最近ではAI活用も似たような問題を抱えており、参加者は自分ごととして捉えやすかったのではないでしょうか。

イベント後の海鮮食堂 すいか 大名での懇親会が大盛り上がりでした。

運営のみなさま、ありがとうございました。

SRE NEXTは仙台、京都、広島、東京等各地で開催!

SRE NEXTは福岡新参者やSREでないアウェイ民にも非常に優しいイベントでした。地方イベントや東京メインイベントもぜひご参加ください。

ではでは。

脚注

  1. 言語によらずIDLのスキーマ定義を見ればAPIがわかる
  2. LXDを提供するCanonical(Ubuntuの開発元)によるとシステムコンテナと対比されるのはDockerのようなrunc等に代表されるアプリケーションコンテナであり、プロセス=コンテナです。https://ubuntu.com/blog/lxd-vs-docker