必要に迫られて掲題のように「第２・４週の水曜日に動く」GitHub Actionsを作らなくてはいかん状況になったものの、ちと手間だったのでメモ。
GitHub Actionsにはschedule triggerがあり、cron式を書くことによって定期的に動作するActionは作成できます。
ただ、これだと毎週水曜日に動くのでここから隔週にしたいです。
しかしながら、schedule triggerだと隔週にするような方法がないため、steps内で第２・４週かどうかをチェックしていきましょう。
こんな感じになりますかね。もしかしたら同じことを実現するworkflowがMarketplaceにあったりするかもしれないけども動いてるのでヨシ！
Artifact Registryの料金にはストレージ料金があり、0.5 GBを超えると1GBにつき$0.1がかかってきます。
微々たる料金ではありますが、運用を続けていくごとに見過ごすことは出来ないコストになる可能性があります。
そこで、GCPでも紹介されている gcr-cleaner を使ってこのコストを低減させてみます。
今回はお手軽にGitHub Actionsを使って、gcr-cleanerを定期実行させていきます。
作成を開始する前にgcr-cleanerについての簡単な説明ですが、様々な条件を元にContainer Registry / Artifact Registryのイメージを削除することができるツールで、条件には「イメージを最低でも3つは残す」や「正規表現に合致した特定のタグを持つイメージを削除」や「一ヶ月より前に作成されたイメージを削除」などが設定できたりします。
では、先に完成形のコードを。
こんな感じで作りました。 解説すると
google-github-actions/auth を用い、Workload Identity 連携を使って特定のサービスアカウントを利用しアクセスするといったようなことをしています。
ステージング/本番はロールバックする可能性があるため、開発よりも多めにイメージを残しているといった感じですね。
Artifact Registryにはクリーンアップポリシーが設定でき、これでリポジトリ内のイメージのライフサイクルを決めることができるのですが、pre-GAの機能なのでGAされれば使うのもいいかもしれないですね。
olderThan / newerThan で期間指定、 keepCount でイメージの保持も出来そうなので過不足はなさそう。
一人でインフラ周りなど色々と見て毎日を過ごしているのですが、ある日「そういえば全然Billing情報確認してないぞ」となり確認してみるとえらいことが。
なんか一部のSKUで料金が爆上がりしてる！！！
サービス全体からするとそこまで大きなインパクトではない額だったのですが、それでも見過ごせない不穏な上がり方です。
10/1を契機に上がっていたので、GCPのお知らせを確認してみると・・・
これや〜〜〜
GKEでContainer Registryを利用していたので、Podを生やす際にContainer Registryからイメージをダウンロードしてくるタイミングで新たにお金がかかるように😇
えらいこっちゃとすぐさまダウンロード時の料金がかからないArtifact Registryへの移行を準備しました。
まずはCDを確認し、Container RegistryからArtifact Registryへの既存イメージのコピーをした上で、Container Registryへイメージをアップロードしている処理と共にArtifact Registryへのアップロード処理も追加することにしました。
変更後のCDをしばらく動かし、アップロードに問題がないかどうかが確認できたらイメージの利用する先をArtifact Registryに変更し、Container Registryへのアップロード処理を削除します。
gcr.io ドメインサポートがされているArtifact Registryリポジトリを生やしてリダイレクトさせるなどの方法もあるみたいなのですが、分かりやすさ優先で上記の方法を取りました。
というわけでArtifact Registryへの移行をすることでサービス全体料金がこんな感じで変化しました。
Oh！結構変わりましたね。毎日の支払状況でこれで、月毎の累積値を見ると大体20%ほどコスト改善出来ました。やったぜ。
というわけで、GCPからのお知らせはちゃんと確認してBillingも確認しようねというお話でした。
Cloud Armorを使っていくつかの国からのアクセスを禁止する場合
origin.region_code == 'JP' || origin.region_code == 'CN'
といった感じでやっていくのですが、対象国が数十件ある場合にはこういったやり方は非常に面倒かつ、一つのルールに対して適用可能な式の数が5つまでなのでルールを分割する必要が出てきます。
なので、こういった場合は
'IE,IT,EE,AT,NL,CY,GR,HR,SE,ES,SK,SI,CZ,DK,DE,HU,FI,FR,BG,BE,PL,PT,MT,LV,LT,RO,LU,IS,LI,NO'.contains(origin.region_code)
といった感じで、羅列したリージョンコードに対してアクセス元のリージョンコードが含まれるかどうかで判別すると良い。（例はGDPR対象国かどうかを判別する式）
Findy社様が開催されたSRE大集合！みんなで学ぶ、信頼性を高めるための取り組みLT大会に登壇させていただきました。
今回はソフトスキルに主眼を置いた内容を発表致しました。
何を発表しようかなと考え、改めて振り返った時に「開発チームに本当に助けられてるなぁ」と感じ、何故開発チームとここまで信頼性を築くことが出来たか？何をやったのか？を自分の備忘録としても書き残しておこうと思い、こういった内容にしました。
SREを実践している人間にとってはコミュニケーションは切っても切り離せない必須スキルです。ただし、「こういった感じでチーム間のコミュニケーションを活発化させているよ！」や「コミュニケーションでこういう失敗をしてしまった！」みたいな成功/失敗問わず、あまりコミュニケーションを取り扱ったLTが自分が見てきた中で少ないように思っておりました。（こんなLTはあったよ！っていうのを教えてもらえると助かります🙇♂）
そういった意味でも、ソフトスキルの話をしてみるかーとやってみましたが、結果として7~8分という短い尺にソフトスキルの話は丁度いいテーマでした。
発表時間的に一人Embedded SREとしてどのようなことを考え、実行しているか？は説明できませんでした。そちらは別のカンファレンスで発表したものを見てくださいとお話はしましたが是非見てもらえるとありがたいです🙇♂
また、ご質問を一ついただきましたが緊張でうまく答えられず申し訳ありませんでした・・・
時間をどうやって捻出しているのか？といったご質問でしたが、プロダクション開発とSREを兼ねていた時だと正直どう工夫しても余裕のある時間の捻出は無理なので、多少は残業なりで頑張るしかないといった回答になってしまいます。
しかしながら、機能開発はやらなかったので特に守らなければいけない〆日があるわけでもなかったので、実際はそんなにカツカツでやってるわけではなかったです。プロダクション開発をずっとやり続けることはしないと開発チーム側に宣言もしていたので、本当に時間的にキツいとなった時にはやめるという選択肢があったのも精神的に楽でした。
あと、それでもキツいと感じる方は一旦比重をプロダクション開発寄りにし、SREは余剰時間で進めていくくらいの始め方でもいいのかもしれません。個人的にいきなり今まで開発をやっていた一人が「今日からSREに100%集中します！」ってのはあまり良くないかなと思っていて、開発チームからすると「こちらの負担が増えることをしようとしている」と心象が悪くなり、反発を生む可能性もあります。（SREの探求の6.1.2 「SREの派遣」に近い話） なので徐々にSREを進めていき、信頼と理解を獲得していくやり方がSRE・開発チームどちらにとっても丸いやり方かと思います。
最後に、基礎的なこと過ぎて書かなかったのですが、信頼性を得るには普段から開発チームとの雑談も欠かさずニコニコと機嫌の良い自分で居るのがコツかもしれません。普段の態度もコミュニケーションにとっては大事なことですね。
というわけで、今回発表を聞いてくださった方や、主催のFindy者様ありがとうございました！
