生涯未熟

生涯未熟

プログラミングをちょこちょこと。

Next.js + TypeScriptな環境にRollbarを組み込んだ（SourceMap対応付）

やってみたのでメモとして書く。

やらなきゃいけないこと

対応しないといけないことは以下になります。

  • CIなどでSourceMapをRollbarにアップロードする
  • productionBrowserSourceMapsを有効化する
  • TypeScriptでSourceMapを有効化する
  • スニペットを組み込む

CIなどでSourceMapをRollbarにアップロードする

今回対応したCIはCircleCIなので、こんな感じで組み込んでみました。

設定している ROLLBAR_CODE_VERSION はdocker build時にARGで渡して、アプリケーションでClientに組み込むようにします。
こうしないとcode_versionをClientとSourceMapで同期できないので、Rollbarからしたらエラーは報告されたけど、どのSourceMapを突き合わせたらいいのか分からなくなるわけです。

あとは、公式でも紹介されているWebpack Pluginがあるのですが（ https://github.com/thredup/rollbar-sourcemap-webpack-plugin ）、正直活発だとは言い難い状況なので今回は使いませんでした。もし気になさらない方は使ってもいいのかも？

productionBrowserSourceMapsを有効化する

Next.jsでは本番環境でのbuild時にSourceMapを出力しないようになっているのですが、 next.config.js で productionBrowserSourceMaps: true とすることで出力するようになりますのでやっておきましょう。

nextjs.org

TypeScriptでSourceMapを有効化する

TypeScriptもやってる人は tsconfig.json にて "sourceMap": true をしておきましょう。 inlineSourceMap ってのもあるのですが、こっちを有効化した場合はNext.jsがどういう認識をするのかは未検証・・・

スニペットを組み込む

最後にクライアントでのRollbarへのエラー送信のためのスニペットを組み込みます。これはRollbarがNext.jsのサンプルを用意してくれているので参考にしてこんな感じで書きました。

docs.rollbar.com

最後に

これで上手く行っていたらエラー時にRollbarに報告されるはずです。
設定できているかの確認方法としては、ブラウザの開発ツールにあるコンソールで window.onerror("TestRollbarError: testing window.onerror", window.location.href) を実行してみたり、スタックトレースがきちんとできているかを確認する方法としてボタンを押したら throw new Error("TestRollbarError"); を実行するようにしたらいいと思います。

あとSourceMapが上手くいっていない時はこんな感じの警告が出るかもです。

私の場合はうまくcode_versionの同期ができておらず、SourceMapをminified_urlからダウンロードしようとしていたため起こっていました。
何かSourceMap周りでうまく行っていないときは、RollbarのProjects -> Source Mapsも確認してみるとそちらでエラーが出ていたりするので確認してみるといいかもしれません。

※この時はcode_versionがクライアントでundefinedを設定していたので上手くいかなかった・・・

正直Sentry使ってたらあんまりハマることなく、スッといけたんだろうな〜と思いつつもRollbarでの対応を書いておきました。 特に選定に制限がない方はSentry使いましょう。

遊撃部隊を立ち上げてみて10ヶ月経った

所属しているチームで遊撃部隊の立ち上げをしてから上期・下期を経て、色々とまとめていきたくなったのでまとめる。

遊撃部隊 is 何？

前段として弊チームではバックエンド・フロントエンド・アプリ・インフラの垣根なく、皆で全領域をこなせるようになろうをモットーで普段の仕事をこなしていますが、それでも個々人の得手不得手がありタスクを持つ人が偏るという現状があります。
その中でも特にインフラを触れる人が少なく、インフラ系統のタスクが拾いきれずに埋もれてしまっていました。私が手の空いた時にインフラタスクをこなしてはいたのですが、それでも片手間では処理しきれないサイズのタスクがチラホラとあり手に余っている状況が続いていました。

こういった事象は他の会社でも起きているだろうと調べてみると、Misocaさんのテックブログで参考になる良い記事がありました。

「重要度: 非常に高いわけではないが、無視できるほどは低くない」「大きさ: プロジェクト化するほどは大きくないが、一人がプロジェクトの片手間でやるには手に余るボリューム」といったこぼれタスクを片手間でやるのではなく、しっかりとチームを組んで対応しましょうというのがMisocaさんがやってらっしゃる遊軍チームでした。
「なるほど、遊軍という概念があるのか」と感銘を受け、マネージャーに掛け合い"遊撃部隊"という名で立ち上げ許可を頂き、たった一人ですが遊撃部隊が誕生するに至りました。

立ち上げからやったこと

まずは対応が必要なタスクの棚卸しから開始しました。弊チームではスクラムを導入しているのですが、そこで利用しているGitHub Projectのボードとは別のボードを作成し、スクラムからは独立して管理するようにしました。
この背景としては、遊撃部隊のタスクとしてDX（開発体験の方）に繋がるツールの調査・検証などストーリーポイントが付けづらいタスクが多いということと、実際にサービスに形作られていくものがあるタスクではないのでタスクの性質が別なものは分けた方がいいだろうという思惑からでした。
ただし、タスク状況が私しか分からないというのは非常に不健全ですので、「今何をやっていてどのようなメリットがあるのか？どのような進捗なのか？」を毎日のミーティングの中で個別に報告するという形式を取っています。

タスクの棚卸しの後は、優先度の高いものから順にこなしながらも「（SRE文脈での）トイルを洗い出す」「アラート類の整理」「開発チームからの不便だと思っている点・アイデアの吸い出し」「DX向上に繋がるツールの調査・検証・導入」を並行しながら行いました。
主に埋没タスクの掘り出しと生産性向上という未来への投資タスクの２軸ですね。独立部隊で活動する意味合いをより強固にするためにも、今あるタスクをこなすことだけに注力した近視眼的な活動だけはやめようと決めていたので、それらの２軸も活動の芯として据えた次第です。
これ以外にも遊撃の名に沿うよう、開発チームで負いきれないバグの調査やQAチームなど部署の離れた他チームへの技術フォローも散発的にやっておりました。（こう書くと何でも屋さんですね😇）

アレコレと書きましたが、この10ヶ月では主にやったことをまとめます。

  • GKE
  • ArgoCD
    • バージョンアップ対応（v1.7 -> v2.3）
    • Syncが回り続ける問題の解決
    • Sync Failed問題の解決
    • migrage jobのSyncが終わらない問題の解決
    • ArgoCDのapp - repo server間の疎通断調査
  • Cloud SQL Proxy
    • バージョンアップ対応
    • imageをalpineベースimageへ変更
    • 終了時にActive Connectionが存在していても終了してしまう問題の解決
  • DX改善
    • 各種アラートの追加・整備（オオカミ少年アラートにならないように）
    • SLAを算出するためにサービスの死活監視の導入
    • リリースPull Requestの自動作成・更新botを導入
    • IAP有効化されているかのチェックbotの作成
    • Workload Identity連携の実施
      • 不要となったサービスアカウントキーを削除できた
    • CircleCIに存在するubuntuイメージやgoogle/cloud-sdkイメージなどのアップグレードに関する調査・対応
    • デプロイ担当決めbotの運用（現在はデプロイフローが整ったため廃止）
    • Renovateの導入とバックエンド/フロントエンドの依存ライブラリアップデート
    • Rollbarの導入
    • Figmaでの新着コメントをSlackへ通知するスクリプト実装
    • ログ情報を構造化ロギングへ対応
    • 開発環境の使用状況の可視化（ 「開発環境の使用状況分かるくん」を作って冗長コミュニケーションを無くした話 - 生涯未熟 ）
  • インフラ
    • 非推奨となったKubernetes External SecretsからExternal Secrets Operatorへの移行作業
    • External Secrets Operatorのv0.4.4 -> v0.5.1へのアップグレードに関する調査・対応
    • IaCリポジトリにHelm Kubeconform Actionを使ったCIを構築
    • インフラドキュメントの作成・整理
    • 廃止された古いTLSバージョンを制限したTLSポリシーの適用
    • 社内セキュリティ脆弱性指摘への調査・対応
    • GraphQLのセキュリティ調査
    • log4j2など緊急性の高いセキュリティ脆弱性への調査・共有・啓蒙活動（社内のセキュリティチャンネルをチェックする癖がつきました）
    • Locustを用いた負荷環境の作成
  • パフォーマンス改善
    • 一部GraphQLクエリのLatency調査・改善
    • 画像リソースが一部外部ストレージへのリクエストになっていなかったので修正
    • CIの高速化（2倍~6倍短縮）
  • その他
    • 開発チームの悩み事の解決
    • インシデント対応・調査のサポート
    • エラーログの調査・トリアージ・共有（最近は自分以外にもやってくれる方が増えました）
    • イベントに向けた負荷調査・他メンバーへの知見共有
    • GCPプロジェクト誤削除に対するインシデントハンドリング・対応・再発防止策の調査・実施（ GCPプロジェクトが削除されたら何が起こるのかメモ - 生涯未熟 ）
    • インシデント発生時対応のドキュメント作成などの文化醸成（ポストモーテムの導入）
    • 退職者に紐付くリソースの調査・対応。必要なものに関してはバックアップ取得
    • 遊撃部隊への相談アワーの実施（遊撃部隊で拾い上げられそうな個々人が抱えているお悩みの共有など）
    • 秘密情報の一元管理化（スプレッドシート管理など散らばっている情報群から1Password管理へ変更）
    • 各種自作ツールのメンテナンス
    • サービスに関するツイートをSlackへ通知するスクリプト実装
    • SlackとGitHubの連携（ユーザー名変換）が上手くいかないバグに対するGitHubとのやり取り対応（結局GitHub側のバグでした）
    • スクラム便利ツールの開発
      • GitHub Project betaで管理しているタスクの各ステータス毎の合計ストーリーポイント数を表示するChrome拡張を作成
      • 特定のステータスのissueに関する特定ラベルを一括削除するスクリプトの作成
      • 機能実装タスクに必須のリリース作業タスクなどのissueを一括作成するスクリプトの作成
      • バーンダウンチャートと付随するスクリプトの作成
    • QA作業円滑化のためのデバッグツールの作成
    • QAで利用しているMagicPodを使った自動化のお手伝い
    • 社内ツールの検証作業

ザッと羅列してみましたが、一人でやっているとこのくらいが限界でした・・・
ここに列挙した以外にも社内関連で採用活動や、社内イベントに向けたアレコレなどをやっていましたが、まだまだやりたいことが多いです🤔
特に最近は色々な会社さんがやられているプレビュー環境自動作成の構築とかはとてもやってみたいですが、なかなか時間が取れず。

ここまで遊撃部隊をやった感想としては、自分にはこういう裏方作業というか縁の下の力持ちな役割が向いていたんだなと気付かされました。こういう発見があるので新しいことに挑戦してみることは良いですね。
あとは遊撃部隊という取り組みを通じて、Googleさんが提唱しているSREという職種についての造形が深くなりました。特にGoogleさんが主催でやってらっしゃるSRE研修に参加させていただたいのですが、何故SREという新しい職種が必要なのか？組織にどういったメリットがあるのかがよりクリアになる良い研修でした。もう少し今やっている様々なタスク群が落ち着けばSLA/SLOの設定などなどSRE活動へ着手していきたいです。

という遊撃部隊を立ち上げてみたまとめでした。

久々にOSSにPR投げてマージされた

とある日、会社で突然CIがぶっ壊れる事象が発生しました。
原因としてはk8sのmanifestsのチェックにkubeconformを使っているのですが、チェックするために利用されるデフォルトのschemaファイルが最近のコミットで変更が加わっていたためです。

github.com ※このissue見て気付いた

で、作者が「デフォルトで使われるschemaファイルは変更したので、k8sのバージョン指定すれば今まで通り使えるよ」という感じのことを仰られていたので、 -kubernetes-version オプションを使ったら一安心・・・
で済めば良かったのですが、会社のCIではhelmを使っている関係上、GitHub Actionsのhelm-kubeconform-actionを利用していました。
helm-kubeconform-actionで -kubernetes-version を実行するようにすればいいじゃんとなるところなんですが、actionのinputに該当する項目が無く・・・とほほ

という流れで久々にPRを投げることになりました。幸い、helm-kubeconform-actionはそこまで重いOSSではなかったので軽微修正となりましたが、久しぶりにOSS作者とやり取りして「ちゃんと作った人って生きてるんだな」と謎の再確認ができました。

github.com

また、ガッツリOSS活動やりたいな・・・

Spring v4.0.0にアップグレードしたらbundle exec rails cが死んだ話

所属チームにRenovateを導入してウキウキ気分で依存ライブラリのアップグレードをやっていたのですが、Springをシュッとv4.0.0にアップグレードしたらbundle exec rails cなどが動かなくなりました・・・

どのように動かなくなったかというと bundle config set without test をやっているのに、何故かtest groupのGemが Could not find で怒られてしまい動かないという。

原因

最初、自分の設定類がおかしいのかと色々ガチャガチャと調査をしていたのですが、そんな折にこのStack Overflowを発見。

stackoverflow.com

で、回答にあったようにv3.1.1にダウングレードしてみると確かに動く🤔

問題となっているISSUEがこちらで

github.com

v4.0.0のアップグレードで今まで Bundler.with_original_env としていたところを Bundler.with_unbundled_env に変更した結果、 BUNDLE_ の環境変数が削除されてしまいました。
何が問題かというと BUNDLE_APP_CONFIG も削除されてしまうので、bundle config内のwithoutが参照できずに本来省かないといけないtest groupのGemもチェックされ、エラーとなってしまった感じですね。

数時間この問題にハマったので、みなさんもお気をつけください👀（ちなみにFix版のv4.0.1はまだ未リリース・・・

Linuxで動かしながら学ぶTCP/IPネットワーク入門を読んだ

bells17さんのメモ書きを読んで、そういえば積ん読になってたな〜と思い出したので引っ張り出して読みました。 zenn.dev

結論から言うと凄い良本でした。

感想

今までこの手のネットワーク本は「ネットワークはなぜつながるのか」くらいしか読んだことがなかったのですが（こちらもネットワークの入門書としては非常に良かったです）、概念は分かったけどももうちょっと具体的なところに手が届いていない感じがありました。そこを補うような内容が本書では書かれています。

最初困ったのは手を動かすための環境作りにvirtual box + vagrantを使うように書かれていたのですが、M1 Macを使っているとvirtual boxを使うことができません。
そのため、GCEでUbuntu 20.04のインスタンスを立ち上げ対応することに。。。

個人的に４章のイーサネットのブリッジの辺りや、NATのところは知識が薄かったので非常に学びがありました。スイッチングハブとリピータハブってそういうことなんだったんだなーとか。

あとは新しい学びというか改めてというところで、DHCPの説明への運びが上手いな〜と思っていて基本的には写経を中心に進めていく本書なのですが、章を進めていくごとに写経量がかなーり増えていきます。で、同じようなコマンドをタイプしまくるのに飽きたところで「DHCPを使えば君たちが今迄タイプしてたことは必要なくなるんだ！」って持っていき方は非常にわかりみが深くなって良い体験でした。

ということで、ネットワークの入門書としてはめちゃくちゃ良本でした。個人的には「ネットワークはなぜつながるのか」で大まかなイメージを掴んでおいて、副読本として本書を併せて読むのがベストなような気がしました。