2021年の振り返り

大晦日なので、(滑り込みですが) 2021年の振り返りブログを書こうと思います。
去年の年末は 2020年に買って良かったモノ のブログを書いて満足してたみたいです。

2021年の振り返り

仕事

システムリプレースを専任で行うチームへ異動し、業務内容や利用する技術スタックに変化がありました。
インフラ関連のリソース (GCP, Datadog etc.) をTerraformで一括管理したり、Python, Typescriptで社内ツールやバッチを書いたりと、去年と比べて業務の幅が大きく広がった印象があります。

また、今年の後半にかけては、インフラ設計から実装まで一気通貫で進めたり、チーム横断でタスクを主導する機会が増えたことも今年の変化として印象的な部分です。
中長期のタスクの進め方・スケジュール管理などの仕事をする上での考え方を自分の頭の中で一から再構成するきっかけになりました。

細かいものを除いて大まかにまとめると、下記のようなことを行っていました。

1~3月

• 異動後のオンボーディング
• 日次バッチ (Python) の実装
• 新環境のMonitoring / Logging周りの整備
  • 監視項目の洗い出し、DatadogのMonitorの整備 etc.

4~6月

• 新環境 (マイクロサービスアーキテクチャ) のインフラ整備
• 運用周りのあれこれ
  • Sentryの本格導入、Terraformのバージョンアップ etc.
• 内製のCLIツール (Typescript) の機能実装
• 去年から導入を始めたSLOについて、導入後の振り返りを実施
  • 会社のテックブログにも書きました

7~9月

• 新環境 (マイクロサービスアーキテクチャ) のインフラ整備
• 会社のテックブログ書いたり、チームでは読書会を実施してました
  • テックブログの内容はこちら

10~12月

• マイクロサービスの共通コンポーネントのインフラ設計・実装
• 運用周りのあれこれ
  • Terratestの導入、既存のインフラリソースをTerraform importする etc.
• 来年度に向けての長期タスクの準備

勉強

年明けから本格的にUoPeopleを再開して、(今話題の?) 数学やCS系のコースを受講しています。
UoPeopleへの入学のきっかけとなったCS系のコースなど、自分が学びたかった内容を受講することができ、モチベーションも去年と比較すると高く保つことができました。

こちらも内容を箇条書きすると、下記のようなことを勉強していました。

1~3月

• 年始はお休みの間、GKEやTerraformで遊んでいました (zennで記事にしました)
  • https://zenn.dev/taxin
• 3月後半からは、black fridayのセールで購入していたバウチャーの期限が切れそうだったので、CKADの試験準備をしていた
  • 使った教材はこの辺り
    • Kubernetes完全ガイド (第1版の方)
    • Udemy (Kubernetes Certified Application Developer (CKAD) with Tests)
    • https://github.com/bmuschko/ckad-prep

UoPeopleは下記のコースを受講していました

• 2021 Jan - 2020-2021 term3
  • Programming Fundamentals (CS 1101)

4~6月

• CKADの試験準備 → CKAD合格
• スキマ時間でTypescriptを書いてた (これもzennで記事にしました)

UoPeopleは下記のコースを受講していました

• 2021 Apr - 2020-2021 term4
  • College Algebra (MATH 1201)
• 2021 June - 2020-2021 term5
  • Introduction to Statistics (MATH 1280)
  • Programming 1 (CS 1102)

7~9月

• 業務関連でインプットしたい知識を下記を利用して勉強してました
  • 実践Django Pythonによる本格Webアプリケーション開発
  • Typescript Deep Dive
  • Vue.js - Tutorial

(その代わりに、UoPeopleはおやすみしていました)

10~12月

UoPeopleは下記のコースを受講していました

• 2021 Nov - 2021-2022 term2
  • Databases 1 (CS 2203)
  • Ethics and Social Responsibility (PHIL 1404)

一方で、zennなども含めた外部へのアウトプットに関しては、今年は寂しい数字となってしまいました。
元々、数値目標も設けておらず業務の忙しさやモチベーションに大きく左右されてしまい、記事を書いた月とそうでない月でばらつきがあります。

• zenn: 7本
• 外部登壇: 0 (登壇未遂が2)

プライベート

プライベートに関しては、正直な所書けるような内容がありませんでした。

元々、旅行やアウトドアが好きな自分にとってはCOVID-19によって外出自粛せざるを得ない状況は非常に辛く、精神的に参っていた時期もありました。
秋頃にかけての感染者数の減少と共に、感染対策をしながらキャンプに行ったりと以前と近い形でプライベートを充実できるようになってきています。

今年のキャンプに関しては、年末にブログ記事にしたので宜しければこちらもどうぞ。

taxintt.hatenablog.com

また、Meety経由で自分で設定している各QごとのOKR設定について壁打ちをしてもらいました。
現在も細々と続けていて、個人OKRを業務・勉強・プライベートにどのように活用していくかは今も試行錯誤していますが、以前よりは効果的に利用できるようになった実感があります。

終わりに

ざっくりですが、2021年の振り返りをしてみました。
振り返ると1年あっという間で色々やってると思いつつ、目標設定やスケジュール管理の面でもう少し密度濃く学習する余地があったなという反省があります。

2022年の目標は別のブログでまとめようと思います。
振り返り書くのがギリギリで、目標を書く時間が無かったとかそういうわけではありません。

皆様良いお年を :)

キャンプの思い出と好きなギアの話(2021年版)

はじめに

こんにちは、@taxin_ttといいます。
普段は、VisasQという会社でSREとして働いています。

この記事は キャンプ Advent Calendar 2021 の16日目です。
(Yoshi Yamaguchi (@ymotongpoo) さん、企画ありがとうございます。)

今回は2021年の振り返りを兼ねて、今年訪れた中でオススメのキャンプサイトや購入したギアについて書いていきます。
(ギアに関する記事が多かったので、少し趣向を変えてみました。)

キャンプを始めるきっかけ

2年ほど前からキャンプを始めたのですが、最初にキャンプに興味を持ったきっかけは「ゆるキャン」というアニメです。
作品の見始めと同時期に、富士山の裾野に位置する ふもとっぱらキャンプ場 でキャンプをする機会がありました。

yurucamp.jp

その一回をきっかけに、次回以降のキャンプを充実させるために作品関係なく装備を揃えていき、気付いたらソロキャンプができるまでになっていたという感じです。

元々は旅行が趣味で、その延長で (旅行も兼ねた) キャンプとして好きになったのですが、COVID-19の影響で鉄道移動を伴う観光が難しくなり、その制限下でも密を避けて外で過ごせるキャンプに行く頻度が増えたというのもハマった要因としてあります。

緊急事態宣言が解除されてからは、キャンプ場の近隣施設も再開してキャンプ → 温泉のような形のキャンプができるようになったので、来年以降もこの状態が続いてくれることを切に願っています。

印象に残ったキャンプ場

2021年は十数回キャンプに行き、山梨、静岡などの関東近郊に1泊2日で週末キャンプに行くことが多かったです。
その中でも印象的だったキャンプ場について写真と一緒にまとめてみたいと思います。
(携帯のカメラで撮った写真なので、画質に関してはご了承ください :) )

雲見オートキャンプ場

www2.wbs.ne.jp

西伊豆の海沿いに位置するキャンプ場で、今年訪れたキャンプ場の中で一番景色が良かったです。
GWの時期に訪れましたが運よく海沿いのサイトを予約することができ、駿河湾に沈む夕日眺めながら道の駅で買った金目鯛の干物を焼いていました。

画像検索などでも確認できますが、海沿いで高台にキャンプ場があるので駿河湾を一望でき、天気が良ければ富士山を見ることもできます。

PICA八ヶ岳明野

www.pica-resort.jp

山梨県の中央道韮崎I.Cから北に少し行った所に位置するキャンプ場で、このキャンプ場も非常に景色が良かったです。
甲府盆地の外れの方に位置していて標高が高いので、真夏の時期に訪れても比較的快適に過ごすことができます。

関連施設が整備されている点も好きなのですが、パークゴルフ場が併設されておりキャンプの合間にパークゴルフを楽しむことができます。
規定打数がかなりシビアなので難易度は非常に高いです。バーディーは諦めましょう。パーかボギーで回れれば御の字です。

(コースをどのように攻めるか考え中の友人)

那須高原オートキャンプ場

www.nasu-autocamp.jp

ここはなんと言っても、ピザ窯が併設されたサイトがあるのが特徴です。
近くのスーパーでチルドピザとトッピング用の具材を買ってピザ窯で焼くだけで、お店で食べるようなピザが楽しめます。

こだわる方はピザ生地や具材も持ち寄って、一からピザ作りをしても楽しめそうです。
周辺にはスーパーや温泉施設もあり、JR黒磯駅 / 那須ICからキャンプ場へのアクセスも良いので初めてのキャンプにはおすすめです。
(冬は寒さが厳しいので、春 ~ 夏の時期をオススメします。)

購入したギア

前述の通りキャンプの機会が増えて、ギアもいくつか買い揃えたのでその中でもオススメの品を2つ挙げます。

UNIFLAME TSURUBAMI 燕三条乃斧

持ち運びのしやすいコンパクトな手斧を探していて、見つけたのがUNIFLAMEの燕三条乃斧です。

全長30cm以下で一般的な手斧と比べて小ぶりですが、フルタング構造になっているので薪割りしやすい針葉樹であれば対応できます。
コンパクトで薪割りも十分にできるので、ソロキャンプでも利用できる手斧です。

www.uniflame.co.jp

広葉樹でも楽に薪割りできる手斧が欲しくなっているのは内緒です。

DOD 秘密のグリルちゃん

メッシュタイプの焚き火台で、個人的に今年一番買ってよかったものと思っています。

メッシュタイプだとUNIFLAMEのファイアスタンド2などが有名ですが、基本的には焚き火専用の用途になっています。
とはいえ、コンパクトで持ち運びしやすいので、「メッシュタイプで調理時にも使える焚き火台ないかなあ...」と思っていたところ、これを見つけました。

www.dod.camp

使い方は、折り畳みの足を出して組み立てて、補助パーツを取り付けるとグリル用としても利用できます。
(補助パーツなしで、単純に焚き火台として利用することもできます。)

安定感もあり、補助パーツの本数を増やすと、ある程度の重量であれば耐えられるので非常に重宝しています。

袋に収納した時のサイズ感はこんな感じで非常にコンパクトです。
(HHKB Type-Sと比較するとサイズ感が何となくわかるでしょうか。)

最後に

今年はキャンプ三昧でしたが、来年はよりキャンプ三昧でやっていきたいと思います。
明日の担当は yu yamada さんです。

UoPeopleでTransfer creditsを実施した時のメモ

概要

5月末に、UoPeopleでTransfer Creditsの申請が完了して48単位の単位移行が完了しました。
この記事では、Transfer Creditsの手続きをどのように進めたかをまとめていきます。
(単位移転は、EC1をpassしてdegree-seeking studentのStatusであることが前提となるので、気になる方はProgram Advisorに確認してみてください。)

www.uopeople.edu

また、申請時に下記のブログに大変お世話になったので、こちらも合わせてお読みいただけると理解度が深まるかと思います。

puchannel.livedoor.blog

medium.com

大まかな流れ

単位移転の大まかな流れは下記の通りです。
このブログでは、2番目のEvaluation reportの発行からまとめていきます。

• (大学などでの)成績証明書の発行
• UoPeople指定フォーマットのEvaluation reportの発行
• Transfer Creditsの申請

Evaluation reportの発行

Transfer credit policyを見ると、Evaluation reportに関して下記のように記載されています。

https://www.uopeople.edu/wp-content/uploads/2020/07/Transfer-Credit-Policy-1.pdf

UoPeople will accept the transferred credits if the credits are from: A non-US accredited institution reviewed by an established foreign evaluation service, that is a member of NACES (http://www.naces.org/) or AICE (http://aice-eval.org/members/)

私はACEIでEvaluation reportを発行しました。
(名前が似ててややこしいですが、ACEI is a Charter and Endorsed Member of the Association of International Credential Evaluators (AICE)なので問題ありません。)

ACEI | About Academic Credentials Evaluation Institute

ACEIのevaluation-serviceのリンク (https://acei-global.org/evaluation-services/) から申請をした上で、下記の書類を郵送してレポートの発行申請を行いました。

• 成績証明書 (英文で発行)
• 卒業証明書 (英文で発行)

申請時には小学校から全ての学歴を列挙する必要があったり、郵送のオプションはデフォルトで付与されていないのでAdditional Feeを払ったりするので確認は必須です。
Reportの発行まで1ヶ月程度かかったような気がします。

Transfer Creditsの申請

ACEIからは下記のような封筒でEvaliation reportが届きます。

img1

次に、UoPeopleのPortal経由で、Admissions > Transfer Creditsから単位移転の申請を行います。
届いたreportはプリンターなどでscanして画像ファイルに変換して、Portalからuploadします。

https://your.uopeople.edu/portal/TransferCredits/default

申請後にApproveされていることを同じページのリンクから確認して、単位移転は完了です。

また、どの単位が卒業要件のどの項目に当てはまるかは記載はないので、Program Advisorに問い合わせて確認を行いました。
(メールで下記のような形でどの項目に紐づくか教えてもらいました。)

Business Strategy : --------- Elective
Corporate Finance : ----------Elective
Corporate Governance : -----Elective
Basic Seminar I/Basic Seminar II ------------ Elective
Health And Sports : --------------- Elective
International Economic Relations --  --------Social and Behavioural Sciences
...

また、UoPeopleのPortalでAcademic Achievements > Degree Audit Reportから、(移転した分も含めて) 詳細な単位の取得状況が確認できます。
単位移転後に、ここで単位の取得状況の詳細を確認しました。

https://your.uopeople.edu/portal/AcademicAchievements/default/DegreeAuditReport

img2

終わりに

一連の申請にかれこれ半年以上かかってましたが、なんとか完了してほっとしています。
引き続きUoPeopleはやれる限り続けていきます。

参考リンク

www.uopeople.edu

2020年に買って良かったモノ

備忘録的に、2020年に買ってよかったものを雑にまとめてみました。
(二番煎じだけど気にしません)

ディスプレイ(BenQ GW2480T) + ディスプレイアーム(エルゴトロン LX モニターアーム)

今年に入ってから在宅勤務になったこともあって、デスク周りは一通り整備しました

座高が高いので、モニターアームで目線の位置にディスプレイの高さを調整できるのが嬉しい
画質的には特に不満は無いので、もう一枚ディスプレイを導入してMacをクラムシェルモードで利用しようかと計画中です

www.amazon.co.jp

Amazon | エルゴトロン LX デスクマウント モニターアーム マットブラック 45-241-224 | エルゴトロン | モニタアーム&スタンド 通販

HHKB Professional HYBRID Type-S 日本語配列

Realforceのキーボードを持っていたので必要なかったのですが、完全に興味本位で購入

karabiner-elementsでのキー配置の調整など初期設定に手間取った記憶があるが、使い始めてからは快適だった
(キーボード自体は小さめなので、手の大きい人は使いづらいかもしれないと思いました)

Amazon | HHKB Professional HYBRID Type-S 日本語配列／墨 | HHKB | パソコン用キーボード 通販

CalDigit TS3 Plus

Mac用のハブとして、配線周りをまとめることができてデスクの見た目がスゴくすっきりしたので満足してる
(今年一番、買って満足度が高かったものかもしれない)

先述のディスプレイとかと合わせると、こんな感じのデスク周りになりました

Amazon | CalDigit TS3 Plus/Thunderbolt Station 3 Plus/Thunderbolt 3 ドッキングステーション（スペースグレイ・0.7mケーブル付き） | CalDigit | ドッキングステーション 通販

Philips Hue

起床時・就寝時のタイマー機能には非常にお世話になっている
たまに家のNWが不調になるので、電気がつけられなくなったりして困ったりするが基本的には便利

Amazon | Philips Hue(ヒュー) | ホワイトグラデーション スターターセット | E26スマートLEDライト2個+ブリッジ1個+ディマースイッチ1個 |【Amazon Echo、Google Home、Apple HomeKit、LINEで音声コントロール】 | フィリップスライティング(Philips Lighting) | LED電球 通販

TRUST THOR LARGE TOTES

気付いたらキャンプ道具が増えていたので収納用のボックスとして購入
後述のハンマー・斧なども雑に荷物を入れても特に傷もついてないので、助かってます

Amazon｜トラスト ソーラージトートウィズリッド TRUST THOR LARGE TOTES with LID [75L/オリーブドラブ]｜収納ケース・ボックス オンライン通販

UNIFLAME TSURUBAMI(燕三条乃斧)

薪割り用に購入
重量もそこまでなく、ソロキャンプなどにも持っていけるくらいにはコンパクトサイズで助かる

Amazon | ユニフレーム(UNIFLAME) TSURUBAMI 燕三条乃斧 684191 | ユニフレーム(UNIFLAME) | 鉈・アックス

MSR STAKE HAMMER

ペグ用のハンマーとして導入
こちらも持ち運びやすいコンパクトサイズで、登山用途でも流用できそう(というかそっちがメインの用途な気がする)

item.rakuten.co.jp

インシデント対応を見据えた監視設計で考えたこと

はじめに

最近、本番環境のシステムの一部移行にあたって、Datadogを利用した監視設計と監視環境の整備を行う機会がありました。

その際の気付き・学びなど振り返りも兼ねて、久しぶりにこのブログを書いています。
特に今回は、アラート対応といった運用プロセスを他チームに移管したこともあり、インシデント対応に少しフォーカスした内容になっています。
(概念的な話がメインとなっており、内容自体はある程度一般化してまとめています。)

監視の基本

前提となる部分で押さえておきたい概念・考え方を記載しておきます。
基本的には「入門 監視」に書いてあることがベースになっています。
www.oreilly.co.jp

正常状態の把握

大前提として、CPU使用率など監視項目の観点で「正常に動いている」とはどういう状態かを定義する必要があります。
特定のAgentやサービスなど稼働を前提とするものがあれば、それも正常状態の定義時に考慮します。

• CPU使用率：oo % 以下
• 通常稼働しているサービス：xxx, xxx

特に、OS関連のメトリクス (ex. CPU usage) はそのままでは利用できないため、正常状態を表現できるように利用する必要があります。

CPU使用率の高騰とサービスが正常に動作しないことは相関がある可能性が高いですが、CPU使用率の高騰 = 正常に動いてない という単純な紐付けは禁物です。

MySQLが継続的にCPU全部を使っていたとしても、レスポンスタイムが許容範囲内に収まっていれば何も問題はありません。
これこそが、CPUやメモリ使用率などの低レベルなメトリクスではなく「動いているか」を基準にアラートを送ることが有益である理由です。
(入門 監視より)

例えば、CPU使用率がoo%を5分連続で超えた場合はサービスが正常ではない可能性が高いと定義して、アラート対応の中でサービスの稼働確認を行う形で利用しています。

OS関連のメトリクスをあえて利用している理由として、正常に稼働しなくなるという予測の観点でもアラートを飛ばすことができるためです。(正確な予測アラートであれば、事象発生前に対応の準備ができるというメリットがあります。)

アラート自体がサービスの稼働確認を行う外形監視も一つの選択肢としてあるかと思います。

継続的な改善

正常状態の把握を踏まえてアラートを設定する場合は、閾値の設定が重要なポイントになります。
oo%をxx分連続で超えた場合は正常ではないのでアラートを発砲する、と定義する際には計測した結果がベースとなります。

過去のインシデントや負荷試験の結果を基に、閾値を仮決めします。
その上で、計測 → 確認 → 閾値の修正 ... といった形で改善フローを回していくと、最終的には正常性を表現できている閾値の設定ができるようになるはずです。

全く同じアプローチで、SLI/SLOの定義と継続的な改善を行うことがベストプラクティスとして紹介されています。
blog.newrelic.co.jp

手順書(runbook)の整備

上記の方法でアラートを設定した上で、アラートに紐づける形で手順書(Runbook)を整備します。
特に、Runbookの整備では属人性を排除することを一番のポイントに挙げています。

より踏み込んだ内容に関しては、この後の部分でまとめます。

インシデント対応を見据えたポイント

次に、インシデント対応に焦点を当てた (Runbookの整備も踏まえた) 監視設計のポイントをまとめていきます。

インシデント対応の全体像

最初に、対応の全体像を把握しておきましょう。
オンコール対応に関する内容なのですが、全体像の把握も含めてPagerDutyのドキュメントが参考になります。
response.pagerduty.com

必要な要素をざっくりまとめると下記の通りです。

• Prepare: アラート設定や対応に必要な権限・環境の整備 etc.
• Triage: 問題の緊急性の判断
• Fix: 事象に対する原因調査・対応
• Improve: 事象の根本解決を想定した対応、ポストモーテムの作成
• Support: オンコールのスケジュール調整、オンコール当番間での引継ぎ

この全体像を踏まえて、インシデント対応を見据えた考慮点をまとめていきます。

アラートの発砲に対する意味づけ

(アラートの重要度の定義にもよりますが) アラートの発砲自体をTriageの第一歩と見なすこともできると考えました。

つまり、アラートによって事象の重大度を表現できるのであれば、それを基に対応フローや別チームのメンバーへのエスカレーションといった後続のプロセスにつなげることができます。
単に事象発生の可能性があるので準備するだけでいいのか、実際に事象が発生しているので早急な対応が必要なのか etc. はアラートそのもので判断できるべきです。
(最近読んだ、Datadogのe-bookにも同じようなことが書かれていました。)

www.datadoghq.com

ここで気をつけたこととしては、アラートで扱う事象のscopeを極端に大きくしないことです。
先ほど記載したような、事象対応への準備や対応といった部分も一つのアラートで扱うのではなく、分けて扱うべきと考えました。

Datadogでは、テンプレート変数を利用して単一のアラート (Monitors) の中で条件分岐をさせて、通知するメッセージと重要度をパターン分岐させることができます。
そのため、管理単位 (Monitors) としては単一ですが、アラートとしては複数種類 (ex. Alert, Warning)のアラートを発砲することができます。

docs.datadoghq.com

単一のMonitorsの定義の中でAlert, Warningの発砲を行う際の閾値を設定します。
Datadogのテンプレート記法の話になりますが、下記のようにAlert, WarnのセクションごとにSlackでの通知時のメンション(@sreteam)と通知先チャネル(@slack-hogehoge-alert-emer)を指定できます。

// alert
{{#is_alert}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-emer 
{{/is_alert}}

{{#is_alert_recovery}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-emer 
{{/is_alert_recovery}}

// warning
{{#is_warning}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-warn 
{{/is_warning}}

{{#is_warning_recovery}}

...

{{!-- \@sreteam --}}<!subteam^hogehoge>
@slack-hogehoge-alert-warn 
{{/is_warning_recovery}}

上記の観点でアラートを整理することによって、アラートに紐づくRunbookに関して手順内の複雑性を最小限にすることができます。

コンテキスト (スイッチ) に対する理解

先ほど、Runbookの書き方について触れましたが、Runbook内のパターン分岐に関しても留意しながら手順を整理していました。

特に、緊急対応が必要な時のパターン分岐・その場での判断は非常にリスクが高く、対応する側としても非常にストレスフルな状態になります。

パターンの漏れが無いように単一のアラートで十数種類の対応パターンを用意しても、対応時に適切な判断ができるかは難しいと思います。
なるべく分岐回数は少なくして、上から手順を流して処理できればベストと感じました。

Slack channelについても同様で、通知されるchannelに関してもコンテキスト (どのような意味合いで利用されているか) を確認して利用する必要があります。

このchannelは全てのメッセージをwatchする、これはちゃんと見なくてもいい etc. のようなchannelごとの暗黙的なコンテキストスイッチが存在する可能性があることに留意しましょう。
(自分の場合は、アラートの種別と通知先について移管先のチームに共有した上で認識齟齬が無いかを確認していました。)

終わりに

以上、インシデント対応を見据えた監視設計で考えたことについてまとめました。

監視設計に関しては、メトリクスの扱いからアラートの中身まで考えることが多く、奥深いなと実感しています。
サービスの安定稼働を裏で支えられる監視設計ができるように日々勉強していきます。

Cloud runでSlack botを作成した時にハマったこと

はじめに

GCPのCloud runを利用してSlack botを作成した際にハマったことを備忘録として残しておきます。

Slack Bot作成時には下記のようなResourceも利用しています。

• Cloud Scheduler: Cloud runのServiceを起動する
• BigQuery: Cloud runからクエリを実行してTableからデータを取得する

Cloud run起動時のService Account

最小限の権限でCloud runを起動する場合には、Service Accountを新規作成して必要なRoleを紐付けます。
その状態で--service-accountのオプションで作成したService Accountを指定してCloud runを起動します。

cloud.google.com

Cloud run→BigQuery(Table)に対してクエリを投げるようなSlack bot(Cloud runのService)には、下記の権限が必要になります。
(SAに紐付けられた権限を用いて、Cloud run上のプログラムでBigQueryジョブを実行してTableを参照するため下記のようになります。)

• bigquery.jobs.create
• bigquery.tables.getData
• iam.serviceAccounts.actAs

cloud.google.com

cloud.google.com

上記の権限を利用するために、Service Accountに対して下記のRoleを紐付けます。

• roles/bigquery.jobUser
• roles/bigquery.dataViewer
• roles/iam.serviceAccountUser

cloud.google.com

(+α)別ProjectのBigQuery(Table)にクエリを投げる

Cloud runが起動しているProject(A)から別Project(B)のBigQuery(Table)にクエリを投げるケースがあります。
先述のBigQuery関連のRoleは、下記のGCP ProjectのIAM RoleをService Accountに紐づけます。

• roles/bigquery.jobUser → Project(A)
• roles/bigquery.dataViewer → Project(B)

これは、BigQueryのジョブをCloud run上から実行することから、roles/bigquery.jobUserの権限はCloud runが属しているProject(A)側にアタッチする必要があるためです。

REST API ライブラリまたはクライアント ライブラリを使用して
プログラムで BigQuery ジョブを実行するには、次のようにします。

  1. クライアント コードによって生成された一意のジョブ ID を使用して、jobs.insert メソッドを呼び出す
  2. 定期的にジョブリソースをリクエストし、ステータス プロパティを調べて、ジョブの完了を確認する
  3. ジョブが正常に終了したかどうかを確認します

cloud.google.com

Cloud Scheduler用のService Account

Cloud Scheduler→Cloud runでServiceを起動する際には、Cloud Scheduler用のService AccountにCloud Run Invokerを付与する必要があります。
(手順的には下記のドキュメントが参考になります。)

cloud.google.com

また、注意点として先述のService Accountとは別にCloud Scheduler Service AgentのRoleが付与されたService Account (service-[project-number]@gcp-sa-cloudscheduler.iam.gserviceaccount.com) が必要になります。

本来は、Cloud Scheduler API を有効にする際に自動的にService Accountが作成されます。
ただし、2019年3月19日より前にこの API を有効にしていた場合は、この役割を手動で追加する必要があります。

cloud.google.com

リージョンを跨ぐ状態でのCloud Scheduler → Cloud runの起動

通常の状態では、(同一のGCP Projectであっても) リージョンを跨ぐ状態でのCloud Scheduler → Cloud runを起動することはできません。

これは、Cloud Scheduler, Cloud runが両方ともRegionに紐づくリソースで、Cloud SchedulerからのRequestはGCPのNetwork(VPC?)を利用するため、VPC周りの設定次第では到達しないためと考えられます。 (明示的に公式ドキュメントに記載してある部分は見つけることができませんでしたが、ahmetb/cloud-run-faqに記載がありました。)

If any other private service (e.g. GCE VMs, GKE) needs to call 
your Cloud Run application, they need to use this public hostname.

However, despite you’re making requests to public IP from a GCE VM 
in the same region (or possibly on cross-region if you're on GCP Premium network tier), 
the traffic won’t leave Google’s own network.

github.com

未検証ではありますが、Serverless VPC Access Connectorを利用することでこの部分は解決できるかもしれません。 cloud.google.com

終わりに

Cloud run自体は簡単に利用できますが、他サービスとの連携面などで注意する点があります。
このBlog記事がCloud runを利用する方の助けになれば幸いです。

転職して一ヶ月経った

tl; dr

色々やっています。
Kubernetesは引き続き細々とやっていきます。
コード書く機会を増やしていきたい。

何やってるの?

8月に転職して某社でSREとして働いています。
転職の経緯などはこちらに記載しているので、よろしければどうぞ。

taxintt.hatenablog.com

今はDatadog使って監視周りの改善活動をしたり、SLI/SLOの導入のためにDesign Docsをベースにチーム用のガイドラインを書いたりしてます。
Monitoring, Logging, Alertingの改善やインフラ更改のお手伝いなど、やることはたくさんありますが楽しく過ごしています。

コードはほとんど書いていません。(もとからそんなに書いてなかったので書く量としてはそんなに変わっていないです。)
Cloud Functionsを触った時に少しGoを書いたり、Pythonを書いたりしたくらいです。

最近やったこと

8月末にCKAを取りました。（Score: 86%）
内容が9月から変わるとのことで、勉強内容自体はあまり参考にならないかもしれないので単体で記事にするのはやめました。

training.linuxfoundation.org

試験対策として、Hard wayを復習したりUdemyのCKAのコースを一通りやったりしました。
Udemyのコースは、Static PodやKubernetes NetworkingのベースとなっているNetwork Namespaceなどが初見の内容も多く、まだまだ知らないことがあるなあ...となった記憶があります。

www.udemy.com

これからやりたいこと

CKAの勉強もひと段落したので、9月以降は隙間時間でコードを書いてきたいと考えています。

理由としては2つあって、一つは技術的な課題に対してコードを書いて簡単なツールが作っていれば「痒いところに手が届く」ケースが増えたこと、もう一つはスキル的に伸び悩みを感じている今の状態から脱却するための足掛かりにしたいという理由です。

ゴリラさんの「プログラミング上達のコツ」をたまたま拝見したり、参加するMeetupの中でインフラエンジニアがコードを書くことに関する話が出てたりする中で、今年の残りはコーディングに力を入れようと思いました。
docs.google.com

インフラに関連する部分で小さなツールをGoで作り始めるところから始めていきたいです。
(なんとなくアイデアはあるので、それを形にするところから...)

最後に

何とか生き残れるように頑張りますので、これからもよろしくお願いします。