GKEノードの自動アップグレードを監視する

所属しているチームでは様々なイベントを監視し、Slackのモニタリングチャンネルへ通知を飛ばしています。

※ エラーログではエラーが発生したCloud Loggingのリンクが貼り付けており、詳細を追従しやすくなっています

この中で、PodのCreate / Deleteを監視しているのですが（画像のPodのデプロイの通知）、デプロイ以外にもGKEノードの自動アップグレードでも通知が飛ぶためその度に「なんで通知走ってるんだっけ？」といった会話がされることがありました。（突然来ると不気味ですしね）

そこで、GKEノードの自動アップグレードがあった際にはSlackへ通知を飛ばすようにしました。

何をしたか？

やったこととしては自動アップグレードイベントを監視するログルーターを作成し、そこからPubSubを通してCloud Functionsを実行し、Slackへ通知を飛ばすようにしています。
今ではCloud Functionsなどを通さずに、ログベースのアラート機能を使うのがベターかもしません。

cloud.google.com

で、通知を飛ばすまでの処理は他の方々の記事で書いてあると思いますので割愛しまして、肝心要の監視するログは以下のようになります。

さて、これでSlackへ通知を飛ばすようにするとこんな感じに。

先程のPodのデプロイの後に自動アップグレードイベントからの通知が来てますね！
ちょっとしたTipsなのですが監視を強化したい方は是非〜

Flutterでログイン後に再インストールしたらログイン済みのままなのをどうにかした

相変わらずFlutterやってるおじさんです。

今回はFirebase Authenticateを用いてログイン済みのユーザーが、アプリを再インストールしたらログイン済みのままになっていたのが気持ち悪いのでどうにかしました。

何故そうなったか？

iOS, Androidともに裏でバックアップを取っていますが（Android: Google Drive, iOS: keychainを使いバックアップ）、これをdisableにしようと思うとAndroidは以下のようにすればいいので簡単ですが、iOSだとちと骨が折れる作業となります。

• AndroidManifest.xml

<application
    android:allowBackup="false"
>
</applicatoin>

そこで、 shared preferences を使って「インストール後、初めて起動した場合にはログアウトさせる」という処理を噛ませることにしました。

pub.dev

基本的な使い方についてはこちらで詳しくまとまってました。

www.virment.com

で、肝心の実装ですが必ず最初に通る main.dart に対して以下のようなコードを実装しました。

shared preferencesで保存した値はアンインストール時に揮発しますので、再インストール時でも問題なくログアウトされます。
こっちの方が楽なのでこういう形で実装しましたが、他に良い方法を知っている方がいらっしゃいましたら教えて下さい！

2021年の振り返り

今年もあっという間に過ぎて１年の振り返りをする時期になりました。
振り返ればブログを開始してから12年経過し、干支も一周するくらい続けてきたなぁと我ながら驚いています。

そんなこんなで今年１年やってきたことを振り返ります。

1 ~ 3月

1 ~ 3月は仕事で開発しているサービスのリリースに向けて、シコシコと開発しておりました。
RoR / GraphQL / Next.js / TypeScript / k8s と割りかし技術的に面白い構成で開発が出来て楽しかったなぁという感じでした。

特にGraphQLは出始めの頃に触った時よりも断然使いやすくなっていて時代の進歩を感じました。

4 ~ 6月

無事サービスのリリースを終えて、開発する傍らGraphQLの負荷検証とかをやっていました。
RoRのGraphQLライブラリである rmosolgo/graphql-ruby を使っていますが、レスポンスサイズが大きすぎるとかなりのレスポンスタイムになるよねみたいなのが問題としてあるので、そういうところは注意が必要みたいなtipsをコツコツ溜めておりました。

github.com

後はインフラ触れる人を増やしたかったので、啓蒙作業のための資料作りなどをやったりしていました。
インフラ触るのに興味持ってもらうの難しいですね🤔

7 ~ 9月

この頃から記事でも書いた開発環境の使用状況分かるくんの開発を開始しました。
それまではサービスの立ち上げに必要な最小限のメンバーで回していたのですが、メンバーが増えるに従って何かしらの仕組みの必要性を感じたために 作り始めた次第ですね。

また、サービス内の検索UIのバージョンアップを行う中でCSSアニメーションを初めて触ったり新しい体験も幾つかありました。

10 ~ 12月

会社から「GCPの資格試験無料で受けれるよ」というお達しに飛びついたので勉強したり、チームが上手く回るための仕組み作りを考え実行したりしていた時期でした。
ポストモーテムを書く習慣作りや、インシデント対応のマニュアルを作ったり・・・

開発面だと負荷検証環境をLocustで構築したりしました。あとローカルで負荷かける時はvegeta使ってたんですが、ちょっと信用ならん結果出しまくってたのでk6に乗り換えました。惰性で使ってるツールはたまには見直さんとダメですね。

会社のアドベントカレンダーにも参加しましたが、まさかあんなにブックマークされるとは思わずビックリしました。
どうせ誰も見ないだろ〜と思ってましたが意外にも需要があるということが分かったので、仕事で得た知識をもうちょっと外に出すことを来年の目標にしたいです。

まとめ

今年もギリギリ生き残れた気がしました。ただ段々と自分の脳みそが衰えてきているのでもっと喝入れて性能戻さんとダメですね・・・
来年も頑張って生き抜こう。

「開発環境の使用状況分かるくん」を作って冗長コミュニケーションを無くした話

本記事は ミクシィグループ Advent Calendar 2021 の22日目の記事です。

前置き

私が現在所属しているプロジェクトでは「アプリケーション × 4 + 開発環境 × 3」という環境で開発しており、機能開発後のQA作業などのため常に３つある開発環境がどこかしら使われているという状況でした。
（ちなみに Fansta（ファンスタ） というプロジェクトですので、興味のある方は @syossan27 までご連絡を！）

そのため開発環境の使用状況をtrelloを使い管理していましたが、新しく開発環境へデプロイする際にはSlackでデプロイしても大丈夫か尋ねる、という流れが定常化しておりました。
このままでも良いのですが、ここはエンジニアとしてこのような冗長コミュニケーションを無くすために技術を使おうじゃないかと思い立ち、カッとなって掲題の「開発環境の使用状況分かるくん」を作成し始めました。

• 開始

  便利ツール作るおじさんになるか

  — しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) 2021年7月9日

• 終わり

  ファ〜〜〜〜〜どこになにがデプロイされたかが分かる君１号が完成した

  — しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) 2021年7月23日

※「どこになにがデプロイされたかが分かる君１号」は開発中の仮称となります

結局、業務時間のスキマ時間を使ってちまちま書いてたら２週間ちょいかかってしまいました。
そして出来たのがこれ！

※左列のアプリ名は別名にマスキングしています

さてはて、この開発環境の使用状況分かるくんの概要と技術詳解を書いていきます。

開発環境の使用状況分かるくん - 概要

画像からも分かるように、開発環境の使用状況分かるくんは各開発環境とアプリケーションのマトリクスで使用状況を表示しています。
これで「今、dev1環境のアプリ１を使っている方いますか？」などの冗長コミュニケーションは防げますね！また、使用状況以外に「何の目的で使用しているのか？」が分かるように「使用中」「空」と書かれている箇所を押下することで、デプロイしたPull Request（以下PR）、またはコミットへ遷移するようになっています。

この開発環境の使用状況分かるくん、一体どこで表示しているかというとGitHubのREADME.md上になります。CLI作って表示させるとかも考えたのですが、「そういえばGitHubのREADME.mdでも表示出来るんじゃない？」と思い付き、エンジニア的にも一番GitHubは見るだろうということでREADME.mdに表示させています。（これが後々面倒なことに...）

あとは、表示させている「使用中」「空」がどのように切り替わるかというと、以下の４つをトリガーに切り替わります。

• PRにて deploy dev_1 といったようなデプロイコメントをすることでデプロイ＆「使用中」へ切り替え
• デプロイコメントをしたPRのマージ or クローズで「空」へ切り替え
• デプロイタグをpushすることでデプロイ＆「使用中」へ切り替え
• 「未使用に切り替え」ボタンの押下で「空」へ切り替え

このような機能になっており、今の所はうまくワークしております。

開発環境の使用状況分かるくん - 技術詳解

ここからが本題の技術詳解です。
とは言ってもそこまで難しいことも無く、構成要素としては以下になります。

• GitHub Actions : デプロイのタグ付け、使用状況データの更新、GitHub Image CDNのキャッシュパージ
• Cloud Functions : デプロイしたPR・コミットへの遷移処理、未使用に切り替えボタン処理
• Cloud Storage : 各開発環境・各サービス毎の使用状況データの格納
• CircleCI : デプロイ処理

これら４つの要素を組み合わせて、使用中/空の切り替えを以下のように行っています。

使用中切り替え

使用中への切り替えは先述したように

• PRにて deploy dev_1 といったようなデプロイコメントをすることでデプロイ＆「使用中」へ切り替え
• デプロイタグをpushすることでデプロイ＆「使用中」へ切り替え

の２つがトリガーとなっています。

デプロイコメントの方ではGitHub Actionsの issue_comment:created を使って、PRコメント/Issueコメントの２つの新規作成を契機に起動するようにしています。

その後if statementでデプロイコメントのみ後続処理へ進むようにし、

1. setup-gcloud を使ったGoogle Cloud SDKのセットアップ
2. github script を使ったPRのブランチを取得
3. リポジトリのチェックアウト
4. デプロイタグのpush
5. 使用状況画像を使用中画像へ置換
6. 遷移先テキストファイルの編集
7. GitHub image CDNのキャッシュをパージ

といった流れで処理していきます。キャッシュのパージは他のGitHub Actionsでも使うので、①~⑥の処理をするGitHub Actionsと⑦の処理をするGitHub Actionsでファイルを分けており、以下のような２ファイルがあるイメージです。

キャッシュのパージについては私が作ったアクションを使っています。詳細は以下の記事に書きましたが、GitHubのREADME.mdにある画像はGitHubのImage CDNにキャッシュされるため、変更を反映するためにキャッシュをパージしています。（これが先述していたREADME.mdに表示するようにしたことで面倒だったところ...）

syossan.hateblo.jp

デプロイコメントをトリガーとした切り替えは説明しましたので、次はデプロイタグをトリガーとした切り替えの説明に移ります。
とは言ったものの基本的な処理はデプロイコメントの場合とそう変わりません。

ちなみにデプロイコメントでデプロイタグをpushしていましたが、この際にデプロイタグのアクションは動きませんのでご安心ください。
（※GitHub Actionsをトリガーに実行する workflow_run 以外はアクションからアクションへの実行は動きません）

あとgithub scriptはめちゃくちゃ便利で、APIドキュメント見て頂けると分かる通りGitHubにおける操作は何でも出来るので使ってみると楽しいです。

github.com

空切り替え

空状態への切り替えですが、こちらは使用中への切り替えとは違いCloud Functionsを使った処理があります。
まずは先に「PRのマージ/クローズ」の実装例を見ていきましょう。

やっていることとしてはPRコメントの走査とデプロイコメントがあった場合の切り替え処理ですね。

次に「未使用に切り替え」ボタンの押下処理を見ていきます。こちらは今までと違い、GitHub Actionsを動かす前にCloud Functionsを挟んでいます。
まずはREADME.mdに配置するボタンは以下のように記述しています。

[![Run Action](ボタン画像URL)](https://[Cloud Functions URL]/example-function?env=app-1&num=1)

これでクリック時に所定のCloud Functionsが動きますので、次はCloud Functionsのコードを見ていきましょう。ちなみに今回は手慣れているGoをランタイムとして作成しました。

そしてCloud Functionsから動くGitHub Actionsが以下になります。

ここまででデータの変更について見てきましたが、最後に「使用中」「空」を押下した時のPR/Commitへの遷移処理を見ていきましょう。これは図にも示した通りCloud Functionsを通してCloud Storageにある遷移先テキストファイルを参照し、記述しているURLへ遷移する流れになります。

最後にREADME.mdに貼り付けるコードがこちらになります。

長くなりましたが、このようにGitHub ActionsやCloud Functionsを用いて開発環境の使用状況分かるくんを実現しています。

やってみて

今回の開発でGitHub Actionsを初めてガッツリ触りましたけど色々出来て面白いですね。大体の欲しいActionはMarket Placeに落ちているので、やりたいことはそれらの組み合わせで済むことが多いかと思います。

github.com

あとはREADME.mdの画像のキャッシュのところはめちゃくちゃ詰まりました。幸いにもこちらのmpywさんの記事を見て「あ〜なるほど〜」となり解決した次第です・・・🙏

qiita.com

久々に業務改善ツール作りましたが使ってくれる人が明確な分、作りやすいですし便利に使ってもらえるところを間近で見れるのはやっぱり良いですね。
皆も自分だけの最強の○○くんを作って日々の開発業務を楽にしよう！！！

Google PCAに合格した

「Googleの資格試験代を補助するので受験したい人〜」と社が募集していたので、これ幸いと受けたら合格しました。

何したか

普段業務でGCPをちょろちょろ使っていたので、その知識＋Googleのオススメ勉強コースに従って勉強しました。
正直、仕事とプライベートが同時に忙しくなってほぼ勉強時間が取れませんでした・・・😇

Googleのオススメ勉強コース

Googleは各種認定資格毎にCourseraのオススメ勉強コースを挙げてくれています。

cloud.google.com

今回はここに記載してある

• Google Cloud の基礎: コア インフラストラクチャ
• Architecting with Google Compute Engine

ぐらいしかこなせず・・・
１コースごとに結構時間取られるので、まとまった時間を取ってガーッと終わらせるのがオススメです。

後は絶対模擬試験は受けておいたほうがいいです。

docs.google.com

実際、受けてみたら模擬試験のような形式で出てきました。
なので試験の雰囲気を掴むためにも、絶対試験前までにやっておきましょう。Cloud Aceさんがブログにて詳解していますので、模擬試験を受けた後に読むとより理解が深まるかとおもいます。

cloud-ace.jp

cloud-ace.jp

受験

オンライン試験とテストセンターでの試験と２種類選べるのですが、オンライン試験はトラブルもあるという話を聞いたのでテストセンターでの試験をオススメします。
テスト内容については結構国語の問題的なものもあるので、問題に添付されている企業情報は必ずじっくり読みましょう。それだけで変な選択肢は弾けるので貴重な試験時間をセーブ出来ます。（割と試験時間がシビア・・・）

あとは、迷うような問題はガンガン「後から振り返る」チェックを付けて進んじゃうのが良いのかなーと個人的には思いました。
全問解いた最後の画面に問題と解答の一覧が表示され、そこに「後から振り返る」でチェック付けた問題が分かるようになっているので残り時間と相談しつつ各個撃破していきましょう。

テストが終了すると最後の画面で小さく合否が表示されるので、見逃さないようにしましょう（もっとデカデカと合否表示してほしい）。

合格後

結果メールが届くのですが、そのタイミングは人や時期によってまちまちで自分の場合は受験から４日後に届きました。
メール内に合格特典コードが書いているので、特典グッズが欲しい人は忘れないうちに申し込みましょう。

↓ こんな感じのラインナップ

まとめ

業務では使っていたけど自分の中であやふやになっていたGCPの知識が強化されて受けてよかったな〜とおもいました。
今ではGCPがよしなにやってくれるところが多くて、細かいところを意識する場面は少ないんですけどね・・・

というわけで、PCA合格記でした。やったぜ。