Terraformに対応していないRemote ConfigをなんとかIaCしてみた

優先度の関係から長らく着手していなかったIaCタスクを進めていたのですが、開発メンバーと1on1した時に「Remote ConfigをIaCして欲しい」と要望を受けました。
たしかにコンソール上からコンフィグいじるの嫌だよな〜というのは薄っすら感じていたのですが、これを機になんとかしてみることにしました。

google-betaにない！！

Terraformにはproviderがありますが、Firebaseのresourceを扱うためにはgoogle-betaというベータ版のproviderを利用する必要があります。

registry.terraform.io

んじゃこれを使えばめでたしめでたし、とはいかず確認したところFirebaseの対応しているresourceの少ないこと少ないこと。
対応しているのは以下になります。

• Firebaseプロジェクト
• プロジェクトのロケーション
• Firebaseアプリ
• Firebase Realtime Database
• Cloud Firestore
• Cloud Storage for Firebase
• Firebase セキュリティ ルール

これだけになります。はい、Remote Configがありませんね・・・

無いならなんとかしよう

まず、この時点でTerraform resourceとして管理するのは諦めました。無いなら仕方ない。
ただ、希望の芽としてFirebase CLIの存在があります。次は、こちら確認してみましょう。

firebase.google.com

デプロイはありませんね😇

ここまで調べたところで8割くらい無理なんじゃないか？と思ったところで、monoさんがzennに書かれていたこんな記事を見つけました。

zenn.dev

おぉ！希望の芽が再び！ということで、プログラム経由で更新することになりました。

デプロイパイプラインを作ろう

さて、プログラム経由で更新するということでCloud Functionsを使ってデプロイをするパイプラインを組んでみました。
概念図はこんな感じになります。

• Remote Configの内容をコードに書き起こしたものを編集し、コミットする
• コミットが通ればGitHub Actionsが発火し、Cloud Functionsに変更した内容を渡して実行する
• Cloud Functionsで渡した内容を元にRemote Configへデプロイする

こんな感じの流れになります。

実装

GitHub Actions

まずはGitHub Actionsの実装です。前提として弊チームのRemote ConfigではJSONのみ扱っているため、それに合わせた実装となっています。

JSONを２つに分けている理由ですが、Remote Configのテンプレートを確認するとコンソールでの設定画面と違い、

{
  "parameters": {
    "info": {
      "defaultValue": {
        "value": "[ここがいつも設定しているコンフィグ情報]"
      },
      "description": "",
      "valueType": "JSON"
    }
}

このような形式で、 value にコンソール画面でいつも設定するようなコンフィグ情報が記載しています。
ただし、この value にはJSON文字列が入っており、視認性が悪いため修正するのにコストがかかります。そこで、テンプレートの土台となる部分と本来の設定したいJSON文字列の部分とでJSONを分けることにしました。

workflowの中でも書いていますが、プロジェクト配下に github_actions/deploy-firebase-remote-config ディレクトリを置き、その中に config.json , info.json の２ファイルを置いております。 config.json がテンプレートの土台で、 info.json が設定したいJSONとなります。なので、開発チームが触るときには info.json を編集し、コミットするという流れになります。

コード自体は難しいことはしていませんが、jqを使ってゴニョっと２ファイルをくっつけているといったところが全てですね。

Cloud Functions

次に、Cloud Functionsの実装です。こちらはmonoさんのコードから大きくは変わらないのですが、こんな感じになりました。

credential は権限を付与したサービスアカウントのJSONファイルの内容を、 databaseURL には https://[プロジェクト名].firebaseio.com を入れてください。前者についてはキチンとSecret Managerで管理するようにしましょう。
あとはよしなにデプロイ結果が分かるようにSlack通知を飛ばすようにしています。

おわり

これでRemote Configへのデプロイパイプラインが組めました。めでたしめでたし。
ありがたいことに開発チームから「便利になった！」という声もいただけて、やってよかったなぁとなったタスクでした。

SRE観点での技術負債 懺悔会 2024 に登壇しました

今回は御縁があってKDDIアジャイル開発センター（KAG）さんとMIXIの合同イベントに登壇いたしました。

mixi.connpass.com

今回のテーマが「SRE観点での技術負債」ということで、私の方からは以下のようなお話をさせていただきました。

speakerdeck.com

このブログではいつものようにライナーノーツとしてお伝えしきれなかったところなどを書いていこうかなと思います。

技術負債とは？

まず、このイベントのテーマである「SRE観点での技術負債」ってなんだろう？と引っかかったので、ここをブレイクダウンしていかないと自分の中でブレてしまいそうだなと思いましたので、技術的負債の定義を経てSRE観点の技術的負債の定義からさせていただきました。

技術的負債については色々な説があると思いますが、なるたけ新し目の説を扱おうということで（古いと時流と合わない可能性が高い）、「Defining, Measuring, and Managing Technical Debt」というGoogleで研究職をやっているCiera Jaspan, Collin Greenの両氏の論文を論拠の土台とさせていただきました。

www.computer.org

スライドでも述べましたが、この論文は技術的負債のカテゴライズ・測定・管理について研究した結果であり、これを基にGoogle社内で数年に渡って改善を行った結果として技術的負債は減ったようです。（とはいえ定量的な数値などが提示されていないので根拠が薄い）

さて、ではその技術的負債の種別とはどのようなものがあるのでしょうか？Google社内で専門家に対してのヒアリングを行った結果、以下の10個のカテゴリが判明しました。一覧の説明を少し手直ししましたので、ここで改めて掲示しておきます。

1. 移行が必要なモノ、または進行中のモノ：スケーリング・依存関係・非推奨などが要因で移行をしなければいけないが、していない or 進行中
2. ドキュメント：ドキュメントが足りていない、完全ではない、見つけにくい
3. テスト：テストが足りていない、脆弱である（Flaky Testだったり）
4. コード品質：適切な設計がされていない、プロトタイプ/デモ版のままである
5. 廃止・放棄されたコード：廃止されたり、利用されていないデッドコードが残っている
6. コードの劣化：時間経過とともにリファクタリングが必要になったコードが残っている
7. チームに必要な専門知識が不足：離職・移動によって人材が不足していたりチーム内で知識を共有する場がない
8. 依存関係：依存先の不安定さ、変化に対する耐性がない、または管理不足である
9. 移行の失敗か、放棄：2つのバージョンが並列で動いている
10. リリースプロセス：リリースプロセスやリリースの監視に対して更新、移行、保守をしていない

この10個のカテゴリがGoogle社内でのインシデント発生要因になった頻度順に並んでいます。つまり、移行をサボっていたことによるインシデントが一番多いということですね。

このように大別された技術的負債を測定して、管理しましょうということが書かれているのですが、そちらの内容の詳しいことは論文をご参照ください。

専門知識の不足については、「プロジェクトコードでTODOコメントが存在することはコード劣化の可能性があり、専門知識が不足している可能性もある」と書かれてもいて、コード劣化と密接な関係にあるというカテゴリは別だが因果関係が近しいパターンもあるようです。

この前提を基に、SRE文脈に変換したのがスライド上に載せてある一覧ですね。

ここで大事なことは「複数の視点を持ちましょう」ということです。プロダクトコードについてのみではなく、自分たちが作ったプラットフォーム・ツール・仕組みについても技術的負債の意識を持たなければいけません。

口頭で喋ったことの補遺

ドキュメントの項で説明したのですが、GitHubのCopilot for Docsは期待していたのですが去年の12月に出たプレビュー終了通知には何の説明もなく非常に残念ですね・・・

GitHub Next • Technical Preview Sunsets

こういったAIを利用したドキュメント管理には期待をしているので、ベスト版がどなたかによって確立された際には徹底的に真似していきたい所存です。

コード品質ではオライリーのソフトウェアアーキテクチャメトリクスの話を少し挟みました。

www.oreilly.co.jp

こうったコード品質メトリクスを静的解析し、結果をPRに貼り付けていけば品質向上の意識付けになるんじゃないかな〜というお話でした。

おわり

今回、登壇させていただきましたが他の登壇者の方々の発表内容の方が数段面白く、正直自分の実力不足を感じました。
もう少し、定義の部分はサッと終わらせて個々にフォーカスした方が面白かったのかな〜とか色々考えましたが、反省は次の登壇に活かしたいと思います💪

MIXI TECH DESIGN CONFERENCE 2024 に登壇しました

去年に引き続き、今年も社のカンファレンスに登壇させていただけました。

techcon.mixi.co.jp

去年と違い、今年はオフラインで会場にいらっしゃった方の前で初めて体験するパネル・ディスカッション形式ということで非常に緊張いたしました。

この記事では喋ったことの補遺というかライナーノーツみたいなことを書いていこうと思います。

他のチーム、職種の方との連携のコツ、取り組み

自分回答はこちら

「職種ごとに目線が違うのでそこを意識すること。非エンジニアの方とやり取りをする場合にはエンジニア間でしか通じない単語などを使わない。あとはベタにteam geekにも書いてあるHRTを大事にする。」

会場でも話しましたが、目線を揃えるということはサイトリライアビリティワークブックの18章にある「目標を揃える」と同義です。SREsが信頼性を尊ぶように、QAチームなら品質、ビジネスチームなら売上が目標となるはずです。
そこをお互いの目標が達成されるように目の前の課題などを乗り越えていく必要性があり、そこを対話によって目線を揃えていくことが大切だと考えているわけです。

sre.google

また、私は小さなベンチャーにいた経験があったので他職種の方と喋る機会が一般的な企業よりも多くありました。その中で培ったコツとして「エンジニア間でしか通じない単語などを使わない」がありました。意外な単語も思い返してみればエンジニア由来だな、というものがあるので一度頭の中で洗い出してみると小さな発見があるかもしれません。

HRTは有名すぎるエッセンスなので特に付け加えることもないですね。社会人として当たり前に身に着けておくべき教養です。

こういったことを意識して接することで、「SREingをやる人」という基本的な認識を持ってもらいつつも、「気軽に相談できる信頼できる仲間」として認知してもらえることを目指すのが良いのかなと思います。

SREの重要性をどう理解してもらうか

自分回答はこちら

「お題目だけの羊頭狗肉と思われないように開発チームにとっての重要なところからSREingを始めてみる。それでも伝わらないなら根気強く重要性を説明し、示していく」

モデレーターの清水さんから「開発チームにとっての重要なところって何？」という質疑がありましたが、開発チームはサービス価値を迅速にユーザーに届けることが重要で、そこに関して一番影響に寄与できるのがCI/CDですね。という応答をしました。

SRE in the Real worldのお話を挙げたのですが、ここでも「最初に始めるべきはdevinfra / relengだ」と述べられており、devinfraはDX（developer experience）の向上を狙った環境作り、relengはRelease Engineeringなので、CI/CDはまさにですね。

blog.relyabilit.ie

SREの人数規模による施策の違い、苦労や工夫など

自分回答はこちら

「一人でSREを実践していますが、リソースがとにかく足りないのでタスクの優先度決めはシビアにやる必要があります。あとはリソース不足の解消手段として開発チームを積極的に巻き込んでいくことです」

こちらも「優先度決めをシビアにやるためのコツはあるか？」という質疑を頂きまして、「コツというか指標はあって"ビジネスインパクトに影響するか？"が第一で、それ以外はチーム全体の影響度の高い低いで決める」と少しボヤッと答えました。
正直、チーム全体の影響度って何だよと思われた方いらっしゃるかもしれませんが、SREsのみに影響が偏るタスクよりもSREsと開発チームのお互いに影響が及ぼされるようなタスクを優先しましょうといった意味合いでした。例えば、「four keysの整備」はどちらかといえばSREs寄りのタスクで、それよりも「リリースサイクルの高速化」みたいなタスクの方を優先度高くしております。

何故そうしているのか？については、開発チームを巻き込むということをやるにあたって開発チームからの信頼貯金を貯めたいという側面が強いです。一人で全てのタスクをこなすといったことは無理に等しいので、貯めた信頼貯金を取り崩しながら開発チームにもSREingに積極的に関わってもらうようにする、といったことが非常に大事になってくるのです。

MIXIのSREでよかったこと

自分回答はこちら

「相談できる人が多いことですね。自分よりも優秀で優しい方々が多く、そこまで緊張せずに相談事が出来るのが素晴らしいです。直近の具体例だとDMARC対応ですぐにSlackチャンネルが立ち上がって助かりました。」

これは自社イベントだから盛って喋ってるんでしょ？と思われるかもしれませんが、誇張なしにそう思ってます。助けられてばかりではいけないので、自分も助ける側に回ろう！としてくれる方も多いので、助けて助けられる相助相譲が文化として根付いているのが本当に良いです。

おわり

というわけで、初めてのパネル・ディスカッションは何とかこなすことができました。また来年もカンファレンスに登壇できるといいな〜。

TechBrew in 東京 〜SRE大集合！信頼性を高める取り組み〜 に登壇しました

気付いたら2024年が始まって３ヶ月記事を書いていなかったことに気付いたので、慌てて書いております。

ということで、2/14にFindyさんが主催の勉強会に登壇させていただきました。

findy.connpass.com

今回はSRE × セルフ・アウェアネスという題材でお話させていただきました。

speakerdeck.com

登壇のお話を頂いたときに「何の話をしようかな・・・」と考えたのですが、自作k8sコントローラを作った話とセルフ・アウェアネスの話と悩んだ末に、後者の話にしました。
正直、前者の話をしてもk8sを扱ってない人からするとピンと来ない話でしたし、もう少し汎用性のある話をしたかったというお気持ちで選択。

さて、今回のセルフ・アウェアネスの話ですが、そもそものきっかけはSREConでの「The Secret Weapon for a Successful SRE Career」というセッションを聞いたことでした。

www.usenix.org

これは、SREを実践するうえで起こる他者とのコミュニケーションなどを円滑に進めるためにセルフ・アウェアネスが有効ですよねという内容なのですが、SREの話題は技術的な話か、非技術的な話だと組織形成などの話がほぼでこのセッションのように「ソフトスキル」を軸にした話を聞いたのは初めてでちょっと衝撃を受けました。
登壇の中でも触れましたが、海外だと日本よりSREポジションにとってのソフトスキルの必要性が言及されており、改めて自分の中でソフトスキルを磨くことへのモチベーションが高まりました。

こういった海外でのSRE × ソフトスキルの話題の例の一つとして、Red HatでSREをやっている方のインタビューpodcastを貼っておきます。transcriptもあるので翻訳して読んでみるとよいです。この中でSREについて「It really boils down to the soft skills, it boils down to culture, it boils down to people. （結局のところ、ソフトスキル・文化・そして人に尽きる）」と仰られていて、非常に共感しました。

changelog.com

このセッションでセルフ・アウェアネスという概念を知りましたが、半年以上折に触れては内省を試してきた結果、自分にとってはかなり有用でした。人とコミュニケーションを取った後などによく「あぁ、なんか変なこと言っちゃったかな？」とか「あれは言わなくてもよかったかな・・・」とか心がウッとなることがあるのですが、適切に内省を行い「何がそう思わせるのか？」「やってしまったとして何がフォローとして出来ただろうか？」など少しは前向きな振り返りが出来るようになり、ポジティブな気持ちを持続できることが増えました。

エンジニアは精神的に病んでしまう方が多くなりがちな職業ではあるので、それを予防するためのセルフ・アウェアネスとしても非常に有効かと思います。こういった本も出ているので、良かったらお試しを。

ハーバード・ビジネス・レビュー[ＥＩシリーズ] セルフ・アウェアネス

あと、今回の登壇の裏テーマは「SRE × ソフトスキルの話が界隈にもう少し増えること」だったので、今後そのようなお話が増えるといいなと願っております🙏

2023の振り返り

今年ももう年の瀬ですね。30歳を越えてからというもの、年々時間の経つのが早く感じられて恐ろしくある今日此の頃でございます。

というわけで今年も一ヶ月毎に振り返ってみましょう。

１月

いきなり病気からスタートだったのですが、年末年始コロナにかかってダウンしておりました。いやー、コロナに初めて罹ったのですが辛いながらも 扁桃腺炎 > コロナ という感じでした。あえて分類するとすれば瞬発的な辛さは扁桃腺炎がダントツで、持続的な辛さはコロナで喉の痛みといった症状は一緒だけれども痛みの度合いは扁桃腺炎が段違いでしたね・・・コロナはコロナで、１月中は咳が止まらなくて生活のしづらさが目立ちました。

何はともあれいい年齢の人間になったので、病気には気を付けたいものです。

さて、１月の大きなトピックといえば年始早々のCircleCIのセキュリティインシデントですね。

circleci.com

弊チームでもご多分に漏れずCircleCIを利用してまして、シークレットの総取っ替えをする必要がありました。 病床についてる最中だったので、大丈夫かしら？と心配でSlackをチラチラ覗いていましたがチームメンバーがササッと対応してくれました。本当に頼りになるチーム・・・！

また、嬉しいことに新しいメンバーを迎えることができ、更にワイワイと楽しく・開発をより進めることのできるチームになったのもの１月のトピックでした。

この頃、自分はというとちまちまとフロントエンドのFragment Colocationの対応をしておりました。この背景としてはover-fetchingが目立つようになり、そこが原因でSSR時にLarge Page Dataで怒られることが増えたことが対応することになった起因です。
この対応についてはマネーフォワードさんのFragment Colocationの記事を大いに参考にさせてもらいました！先人の方々の残してくれている知識には感謝しかないですね🙏

zenn.dev

あとは新婚旅行として人生で初めて沖縄に行ってきました。あまりアウトドア・アクティビティが得意な夫婦ではないので、オフシーズンの安い時期な沖縄をチョイスしてのんびり色んなところを巡ってきました。
中でも由布島に行ってきたのですが、沖縄の中でも特に自然が満載で良いリフレッシュになりました。関東ではなかなか自然に囲まれる経験もできないですしね。あとは牛車で島間を往来するのも良い経験になりました。

※いませんでした・・・

２月

２月からはチームメンバーの発案でエンジニア会と呼ばれる２週間に一回のダッシュボードの観測や気になるエラーログの振り返り、エンジニアリング課題の共有などを行う定期会を開催するようになりました。今でも続いているのですが、作成したダッシュボードを活用する良い機会となり、もっと早くやっておけばよかったなぁと反省です。

インフラ関連で言うとGKEの負荷分散をコンテナネイティブの負荷分散に切り替えることをしました。切り替えの理由としてはサービスで少数ながら502が出ていて、調査したところInstance Groupを通したHealth Checkが70s間隔で、削除予定のnodeが存在した場合に最大70sは疎通ができていなくてもリクエストを送り続けていたため502が出ていました。
Instance Groupを通している場合でもHealth Checkの間隔自体は少なくするで対応できるものの、コンテナネイティブ負荷分散にすることでNGINXのgraceful shutdownも効くようになり、より502が出る可能性を低くすることが狙いでした。
結果、502が出ないようになり切り替えは成功でした✌

あとはMIXI Tech Conferenceに登壇することとなり、登壇資料を作成するのにめちゃくちゃ頑張ってました。

techcon.mixi.co.jp

大きな場での登壇というのが初でもあったので、ネタ出しに非常に苦労しました・・・

speakerdeck.com

結果として大きな場でも小さな場でもちゃんと準備さえしていれば何も変わらないなぁということが分かったので、何事も経験かなと登壇依頼を受けましたが良かったです😊

３月

この辺でめちゃくちゃbotからのアクセスが増えてきました。オートスケールが走るレベルで定期的にやってくるようになってきたので、こりゃどうにかせんといかんとCloud Armorを導入しました。
Cloud Armorでは事前構成WAFルールというものがあり、これを利用することで簡単にSQLインジェクションやクロスサイトスクリプティングなどを防ぐことができます。感度などのレベルを調整する必要があるものの、これ幸いと利用しております。このおかげで今ではbotからの悪意のあるアクセスはほぼ防ぐことができました。

syossan.hateblo.jp

※こういうこともありました

GKEアップグレードやArgoCDのアップグレードなど定常的なアップグレードをこなしつつ、GCのイメージ管理をContainer RegistryからArtifact Registryへ移行しながらgcr-cleanerを使ったStorageの古いイメージの削除をやるなどコスト面に関する作業もちらほらとやっていました。

syossan.hateblo.jp

４月

またまた旅行の話なのですが、これまた人生で初めて金沢に行きました。今回は兼六園がメインターゲットで、これで日本三大庭園を全て回ることができました！

それともう一つのお目当てがナガノ展でして、夫婦揃ってちいかわが大好きで以前東京開催を申し込んで落選してしまったナガノ展の金沢開催が当選したので行ってきた次第です。これまた最高のコンテンツでした・・・！

仕事ではk8sのDeschedulerを試して引き続きコスト面を気にした対応をしたり、レイテンシーやエラー率をまとめたちゃんとしたダッシュボードをLooker Studioで作成したりしてました。
あとはGitHub Actionsを workflow_call を使って、一つのリポジトリで管理するようにしました。これは再利用のためなどの理由もありつつ、本番環境へのデプロイ時にGitHub Actionsなどのコミットがあると開発チームから「デプロイしても大丈夫ですか？」と確認の連絡が飛んできてしまうので、それを防ぐ意味合いもあります。

また仕組み作りではステージング環境のデータを本番環境と同期させたいよねという提案があり、これを実現させるためにゴニョゴニョ動いていたりしました。

syossan.hateblo.jp

５月

2023年6月に改正電気通信事業法が施行されるということで、ユーザー情報を外部に送信しているサービスは何か？などをまとめたりしていました。こういったオーダーが飛んできた時に優先度組み換えて対応しやすくする"遊撃部隊"というポジションを立ち上げておいて良かったと思いますね。

また、ありがたいことにFindyさんのこちらのイベントにも登壇させていただきました。

findy.connpass.com

speakerdeck.com

会社でのグレードが上がったこともあって、こういった外部登壇を増やしていこうと今年は登壇頑張りました。来年も機会を見つけてどこかで登壇したいなぁ・・・

プライベートではマハラージャンのライブで初めて野音に行ってきました！来年の10月に建て替えが始まるということでその前に行くことができて嬉しかったです。やっぱり野外でのライブはいいですねぇ。

６月

GDPR対応が突然降ってきたので対応しておりました。ちょうどCloud Armorを適用していたのでこれを使って解決することに。

syossan.hateblo.jp

あとはSlackのTwitter共有仕様変更に伴って、自前で動かしていたTwitterのエゴサ結果のSlack通知が上手く動かなくなってしまったのでIFTTT Proを契約してTwitter AppletからSlackへ通知を飛ばすようにしました。こういうビジネス側の要求も後回しにせずに優先して対応することは心がけております。

インフラ面だとk8sの特定のPodのリソース状況によってevictさせる君を作ったりしました。

syossan.hateblo.jp

「実践入門 Kubernetesカスタムコントローラーへの道」も有り難く読ませていただいたのですが、本当にk8sは学べることが満載で沼ですね。もっとガッツリ触ってみたい・・・

７月

このあたりで恥ずかしながらOpenTelemetry（以下OTel）について初めて触れました。まだサービスには導入できていないのですが、OTel自体はめちゃくちゃ気になる技術領域なので遅々ながらも追いかけていきたいなという所存です。（日本語のOTel本とか出ないかな・・・

それとフロントエンドの依存ライブラリアップデートもやっていました。定期的にやってくる作業ではあるのですが、本当に影響範囲ややることが多いので一人でやるのはしんどいですね・・・
とはいえ泣き言も言ってられないので、やるしかないのですがある意味ついでによろしくないところも直すことが出来る良い機会と思ってモチベーションを無理やり上げてやっていました。

syossan.hateblo.jp

あと、かたいなかさんが呟いていたこちらに反応した結果、後のゆるSRE勉強会を開くきっかけになったのも７月のトピックでした。

SRE寄りの話題でしゃべれるゆるめの勉強会欲しい

— かたいなか (@katainaka0503) 2023年7月14日

ちょうどSREについての勉強会ってもっと初心者向けというかゆるっとしたものはないかな〜？と考えていたりしたので、喜んで一緒にやることにしました。声をかけていただいたかたいなかさんには感謝です🙏
以前のコミュニティ活動で色々とあり、運営に関わるかどうか悩んだのですがやることにした心境についてはまたどこかで一筆書こうかと思います。（しずかなインターネットあたりで・・・

SRE NEXT 2023のプロポーザル受付が始まったのもこの時期ですね。今年はMIXI Tech Conferenceにも出たことですし、カンファレンスに登壇したいな〜という気持ちがちょうど高まっていた時でしたので練りに練ってプロポーザルを送りました。LTとかだと何かしらのTipsを持って帰って頂こうという気軽な感じで登壇できますが、カンファレンスの場合はもっと体系的な何かを持って帰ってもらうことを考えなければいけないので難しさが段違いでした。

８月

こちらの勉強会に参加したりしました。

offers.connpass.com

syossan.hateblo.jp

個人的に職種というものはあまり意味がないと思っていて、ワンチームで何かしらの問題に立ち向かうべきではあると思うんですよね。ただ、便宜上それでは得手不得手によって特定の人に負担がかかったり、専属チームを作ることにより相乗効果を生むために職種というものを作るというのは納得しているような側面があります。
そういった自分の考えとしてもこの勉強会が言わんとしていることは非常に納得感があり、満足感のある勉強会でありました🙏

他にも

findy.connpass.com

kinto-technologies.connpass.com

などにも参加させていただきました！

あとはFour Keysの取得に向けてアレコレやりだしたのもこの時期ですね。７月にGitHubがメトリクス取得のGitHub Actionsを出したことで、かなりFour Keysが取りやすくなったのでは？と思い、長らくTODOリストに積んでいたのを進めることに。
タスク優先度が常にガチャガチャ変わっていく中で、まだダッシュボードに反映するところまではいけてないのですが来年こそはやり切りたいですね・・・！

そして待望のゆるSRE勉強会の第一回目が開催できました！

yuru-sre.connpass.com

ありがたいことに多くの人にご参加いただけました。今までにも技術コミュニティを運営していたことがあったのですが、その中でも第一回目からここまで盛り上がるのは初めてのことだったので、SREの皆様の注目度が改めて感じられました。

９月

社内でGitHub Copilot導入に向けての機運が高まり、どのようにやっていくべきか？の取りまとめをやったりしておりました。最終的に年の瀬である今週に導入することができたので、来年からはチームの生産性が3000倍くらいになることを期待しております。

またTerraformを使ったIaCをやっていかないとなぁというお気持ちを長らく持っていましたが、ようやく動き出すことができました。まだ全てのIaC化は完了してはいないのですが、来年こそは・・・！こういう時にせめてあと一人SREポジションの人がいればなぁと思ったりします。

あとはGraphQLの一部クエリの速度改善にも着手しておりました。graphql-rubyを使っているのですが、レスポンスサイズが大きいクエリについてはサッパリ性能がでません。以前から認識していた問題ではあったのですが、結果としてはgraphql-ruby自体に手を入れないと何ともならんなぁというあまり喜ばしくない結果となりました。graphql-rubyにPR送るモチベーションも特に無いので、こういう時に代替ライブラリがない言語はめちゃくちゃ困りますね。（Goだとどれだけレスポンスサイズが大きくなってもレイテンシ増大しないのに、なんでこのライブラリはこうなの？ってissue読んで何かがポッキリ折れた

末にはSRE NEXT 2023の登壇がありました。SRE NEXTについての想いは以下に書いたのですが、そんな場に立てることができて光栄でした。

syossan.hateblo.jp

syossan.hateblo.jp

今年の登壇で持てるネタは割りと放出した感があるので、来年またプロポーザル送るかどうかは悩ましいですが是非ともトライはしてみたいです。

１０月

GKEのPodから外へのアクセスに対して出口IPを固定したいというリクエストが来たので、その対応にSquidを使ったプロキシサーバーを建てることで対応したりしていました。

syossan.hateblo.jp

あとびっくりした事態といえば、Bitriseのワークフローが一つ謎にスタックして数十時間動いているという事態がありました。カスタマーサポートに連絡することで請求自体は事なきを得ましたが、いやはや心臓がキュッとなりました。

syossan.hateblo.jp

１０月といえばゆるSRE勉強会の第二回を開催しました。

yuru-sre.connpass.com

第二回も変わらず多くの方にご参加頂いて感謝しかないです。第一回から引き続いて参加された方も多く、満足度の高い勉強会になって良かったと運営視点では安堵したりしていました。

また、プライベートではオクトーバーフェストに行ったりしました。ドイツの地ビールは苦味がキリッと効いていて良いですね！また来年も行きたい🍺

１１月

以前に少し進めていたGitHub Copilotの導入について、もっと急いで！という上からの圧力を感じられたので進めることに。他部署でいち早く進めている部署がありましたので、残していただいていた資料を元に円滑に導入を進めることができました🙏
GitHub Enterprise Cloudへの移行という珍しいタスクをこなすことができて貴重な経験となりました。

syossan.hateblo.jp

弊チームではE2EテストにMagicPodを利用しているのですが、Flutter対応されたということでそちらの対応を進めていました。とはいえ、やったことはBitriseのワークフローを少し弄ってMagicPod向けのアプリをビルドしてQAチームに配信するといったことですね。

あとはコストについて見直す必要があり、GCを中心としたコスト見直しをすることになりました。開発を優先してこういったところはかなりおざなりになっていたので、無駄なところを是正する良い機会でした。今では30%ほどコスト最適化することができ、色々と知見を貯めることができました。

syossan.hateblo.jp

１２月

ついに今月まで来ましたが、GitHub Copilotの導入について引き続き進めていたり、GMailのメール送信者ガイドラインに則ってDMARC対応を進めたりしておりました。

www.nri-secure.co.jp

正直メール周りは門外漢だったので、キャッチアップにかなり苦労しました・・・メール周りムズカシイ・・・

CloudNative Days Tokyo 2023に参加させていただいたのも記憶に新しいです。ゆるSRE勉強会にも参加されていた方が何人か登壇されていたりしたので、すごいな〜と思いながら拝聴させていただきました。

event.cloudnativedays.jp

ゆるSRE勉強会の第三回目も今月開催しました！

yuru-sre.connpass.com

インフルエンザも流行っていたのでキャンセルされる方が多くいらっしゃいましたが、それでも多くの方に参加いただき盛り上がりました！毎回、会の終わりに次回の開催予定を公開していましたが、今回はそれをせずに次回の開催はお楽しみに・・・という感じにしております。裏で色々と企画はしておりますのでお楽しみに！

まとめ

今年も振り返ってみると色々やったような、まだ足りないような・・・一人でやっているということを言い訳にせず、もっと１日１日の密度を濃くしてガンガン進めていかないとなぁと周りの皆さんの活動を見ていたら気が引き締まる思いです。

何はともあれ、自分ももういい歳ではあるので体調には気を付けて来年も更に頑張っていきたいです🙏