Vercel へのビルド&デプロイをローカル環境から行う

この記事は個人ブログと同じ内容です

www.ritolab.com


Vercel は、モダンなウェブアプリケーションの開発、デプロイ、ホスティングを簡単かつ効率的に行うためのクラウドプラットフォームです。AWS Amplify, Firebase Hosting, Netlify, Heroku あたりと同じ位置づけのイメージ。

基本的には、Vercel と Github を連携させるだけで、開発ブランチプッシュやプルリクエスト作成時にプレビュー環境を構築してくれたり、デフォルトブランチにマージしたら本番環境へデプロイしてくれたりなど、簡単に運用が行える点が魅力です。

そんな中、今回は、ローカル環境から WEB アプリを Build し、Vercel へのデプロイを実施してみます。

Vercel CLI

ローカル環境からビルドやデプロイを行うときは、Vercel CLI を用います。まずは Vercel CLI をインストールします。

Vercel CLI インストール

pnpm i -g Vercel

バージョン確認

Vercel --version

認証

Vercel CLIでは、リソースにアクセスしたり管理タスクを実行したりする前に、ログインして認証する必要があります。ターミナル環境では、手動入力が必要な Vercel login を使用できます。

ちなみに、手動入力が不可能な CI/CD 環境の場合は、トークンページでトークンを作成し、--token オプションを使用して認証することができます。

Vercel login

以下の選択肢が表示されるので、自身がいつもログインしている方法を選択します。

? Log in to Vercel
Continue with GitHub
Continue with GitLab
Continue with Bitbucket
Continue with Email
Continue with SAML Single Sign-On
─────────────────────────────────
Cancel

選択するとブラウザが開くのでログインすれば認証が完了します。

プロジェクト設定の取得

ローカル環境でビルドを実行するために、予めプロジェクトの設定を取得しておく必要があります。Vercel pull コマンドで、プロジェクト設定をローカルに作成します。

プロジェクトをすでに作成済みであればこのとき、環境変数も作成されます。プレビュー環境や本番環境で設定している環境変数が別々の場合も多々ありますが、--environment オプションをつけることで、指定した環境のプロジェクト設定を作成できます。

Vercel pull --environment=preview

Vercel pull --environment=production

Vercel pull コマンドを実行すると、以下のように対話型で進むので、適宜入力していきます。

? Set up “~/path/to/your-project-root”?(セットアッププロジェクトの確認)
? Which scope should contain your project?(組織・個人などスコープの選択)
? Link to existing project?(既存のプロジェクトとリンクさせるか)
? What’s the name of your existing project?(プロジェクト名の入力)

🔗  Linked to your-scope/your-project-name (created .Vercel and added it to .gitignore)
> Downloading `development` Environment Variables for Project your-project-name
✅  Created .Vercel/.env.development.local file  [176ms]
  • ? Set up “~/path/to/your-project-root”?(セットアッププロジェクトの確認)
    • Vercel pull コマンドを実行した、ローカル環境の現在位置にプロジェクト設定を保存することを確認
  • ? Which scope should contain your project?(組織・個人などスコープの選択)
    • Vercel のアカウントについて確認される。個人アカウントしかなければ 1 つだけだし、例えば有料でチームを作成していたりすれば、どれをスコープとして使用するかを選択できる
  • ? Link to existing project?(既存のプロジェクトとリンクさせるか)
    • すでに Vercel 上にプロジェクトがある場合は、y(yes) を入力し、次でプロジェクト名を入力する
    • no の場合は、新しくプロジェクトが作成される
  • ? What’s the name of your existing project?(プロジェクト名の入力)
    • リンクさせるプロジェクト名を入力

Vercel pull が完了すると、.Vercel/ ディレクトリが作成され、その中に環境変数ファイルと project.json が作成されます。

.Vercel
├── .env.xxx.local
└── project.json

ビルド

Vercel build コマンドを使用して、ローカル環境で Vercel プロジェクトをビルドします。

Vercel build コマンドは、Vercel プロジェクトをローカル環境または独自の CI 環境でビルドするために使用できます。

# プレビュー環境用ビルド
Vercel build

# 本番環境用ビルド
Vercel build --prod

ちなみにこのコマンドは、ビルドエラー時のメッセージをローカル環境で受け取れるので、普段クラウドでビルド&デプロイしていたとしても、クラウド上でのエラーの原因調査など、Vercel プロジェクトのデバッグにも役立ちます。

ビルド成果物は、Build Output API に従って .Vercel/output ディレクトリに配置されます。

.Vercel
├── output/ # ここにビルドされたソースコードが配置される
├── .env.xxx.local
└── project.json

デプロイ

ビルドができたので、これを Vercel へデプロイします。

# プレビュー環境用デプロイ
Vercel deploy --prebuilt

# 本番環境用デプロイ
Vercel deploy --prebuilt --prod

--prebuilt オプションをつけ、ローカル環境のビルド済みソースをデプロイします。

ビルドコマンドもそうですが、--prod オプションを付けなければ、プレビュー環境用のデプロイになります。

% Vercel deploy --prebuilt

Vercel CLI 36.0.0
🔍  Inspect: https://Vercel.com/aaaa/bbbb/cccc [2m]
✅  Preview: https://xxxxxxx.Vercel.app [2m]
📝  To deploy to production (xxxxxxx.net +1), run `Vercel --prod`

デプロイ URL とプレビューの URL が表示されるので、デプロイが終わったらアクセスすると、動作確認ができます。

ここで示される デプロイ URL とプレビューの URL は、Github プルリクエスト時に提示されるものと同じ URL です。

プレビュー環境で動作確認を行った後、本番用にビルド&デプロイを実施すれば、ローカル環境から Vercel へデプロイ完了です。

まとめ

ローカル環境から Vercel へ web アプリケーションをデプロイするには、Vercel pull, Vercel build, Vercel deploy の 3 つのコマンドを実行すればデプロイできます。

例えば、環境切り替えも含め、これらのコマンドをまとめたシェルスクリプトなどを作成しておけば、デプロイはかなり簡単になります。

冒頭にも述べた通り、基本的には、Vercel と github を連携させるだけで CD 環境が構築されるため、通常なら使用しない場合も多いと思います。

ローカル環境からデプロイする必要が生じた際には、参考にしてみてください。

XP入門

この記事は個人ブログと同じ内容です


はじめに

今年の6月からスクラムマスターの役割を担うことになりました。 しかし、私自身現在の会社に勤めるまでアジャイル開発の経験が全くなかったので、理解を深めるために XP について学ぶことにしました。 この記事はケント・ベック氏によって著された「エクストリームプログラミング」の7章までの読書メモと感想です。

XP とは

XP (エクストリームプログラミング)は、アジャイル開発の手法の一つです。 エクストリームは日本語で「極限」という意味で、柔軟な変更や継続的な成長により開発プラクティスを極限まで洗練させ、品質の高いソフトウェアを効率的に開発することを目指します。

価値、原則、プラクティス

XP には、価値、原則、プラクティスがあります。 本書では、イチゴ栽培を例に挙げて説明されていました。

イチゴの隣にマリーゴールドを植える = プラクティス
マリーゴールドはイチゴを食べる虫を寄せ付けない = 価値
隣り合った植物がお互いの弱点を補う(共生栽培) = 原則

この例と本書に書かれている他の内容を基にした私の理解は以下です。

プラクティス = 実際の行動
価値 = プラクティスによって生まれる恩恵、目的
原則 = プラクティスと価値の橋渡しをするもの、活動指針

次からそれぞれについて詳しく内容を見ていきたいと思います。

価値

XP では、個人としてではなく、チームや組織の一員としてどのように振る舞うかに重きを置いています。 全員がチームにとって大切なことに集中するとしたら、何をするべきかについて5つの価値が定義されています。

  • コミュニケーション
  • シンプリシティ
  • フィードバック
  • 勇気
  • リスペクト

コミュニケーション

  • 開発中に問題が発生したときには、すでに誰かが解決策を知っていることが多い。だがその情報は変更する権限のある人には伝わらない。
  • 予想外の問題に遭遇した際、コミュニケーションが解決につながる可能性がある。過去に同じような問題を経験した人に話を聞くこともできるし、問題の再発防止についてチームで話し合うこともできる。
  • チーム感覚や効果的な協力関係を生み出すために重要なもの。

シンプリシティ

  • ムダな複雑性を排除するために、何ができるかを考える。

フィードバック

  • 一時的な完成に期待するよりも、常に改善を続けていくことが大事。
  • XP ではできるだけ早く、できるだけ多くのフィードバックを生み出そうとする。
  • フィードバックが早く手に入れば、その分だけ早く適応できる。

勇気

  • 今までのやり方を急激に変えたり、あるいは、今までのやり方を否定するような変化を受け入れることが必要。
  • 勇気のみでは危険だが、他の価値と合わせれば強力。
  • 「勇気」を持って真実を語れば、「コミュニケーション」や信頼が強化されていく。
  • うまくいかない解決策を捨て、「勇気」を持って新しい解決策を見つければ、「シンプリシティ」が促進される。

リスペクト

  • チームメンバーがお互いに関心がなく、何をしているかを気にもとめないようであれば、XPはうまくいかない。
  • チームメンバーがプロジェクトを大切にしないのであれば、何をしたところで開発は成功しない。
  • ソフトウェア開発において人間性と生産性を同時に高めるには、チームに対する個人の貢献をリスペクトする必要がある。

原則

価値は抽象度が高いので、そのままでは振る舞いの指針になりません。 そのため、XP では価値の指針となる原則が定義されています。

  • 人間性
  • 経済性
  • 相互利益
  • 自己相似性
  • 改善
  • 多様性
  • ふりかえり
  • 流れ
  • 機会
  • 冗長性
  • 失敗
  • 品質
  • ベイビーステップ
  • 責任の引き受け

このうち私が興味を持った原則をいくつかご紹介します。

人間性

  • 人間がソフトウェアを開発する。これはシンプルで逃れようのない事実。
  • 優れた開発者になるには、何が必要だろうか?
    • 基本的な安全性 - 空腹、身体的な危害、愛する人を危険にさらすものが存在しないこと。
    • 達成感 - 自分が所属する社会に貢献する機会や能力
    • 帰属意識 - グループに所属して、承認や説明責任を受け取ったり、共通の目標に貢献したりすること。
    • 成長 - スキルや視野を広げる機会。
    • 親密な関係 - 他人を理解して、他人から深く理解されること。
  • チームによるソフトウェア開発で難しいのは、個人の欲求とチームのニーズの両方のバランスを取ること。
  • 優れたチームが素晴らしいのは、メンバーたちが信頼関係を築き、一緒に働くことによって、みんなが自分らしくいられること。

相互利益

  • あらゆる活動は、関係者全員の利益にならなければいけない。
  • 相互利益とは、最も重要であり、最も実行が難しい XP の原則。
  • XP の相互理解は、現在の自分、将来の自分、顧客に対する利益を求める。
  • 将来とのコミュニケーションの問題を相互利益になるやりかたで解決する例。
    • 現時点で設計や実装がうまくできるような自動テストを書く。また、テストは将来のプログラマーにも使えるように残しておく。こうすることで、現在の自分と将来の保守担当者の両方の利益になる。
    • 意図しない複雑性を排除するために、注意深くリファクタリングする。自分の満足感が得られ、欠陥が少なくなり、あとでコードに触れた人が理解しやすくなる。

多様性

  • 問題や落とし穴を見つけたり、問題を解決する方法を複数考えたり、解決策を実現したりするためには、さまざまなスキル、考え方、視点を組み合わせる必要がある。つまりチームには多様性が必要。
  • 多様性には衝突がつきもの。
  • 衝突が発生しないチームなど存在しないので、生産的に衝突を解決できるかどうかを考えてみる。
  • みんなをリスペクトして、自分の言い分を主張すれば、ストレスのかかる状況でもコミュニケーションは円滑になるはず。

品質

  • 品質を犠牲にするのは、効果的なコントロール方法ではない。
  • 品質は制御変数ではない。
  • 低品質を受け入れることで、プロジェクトが早くなることはない。
  • 高品質を要求することで、プロジェクトが遅くなることもない。
  • むしろ品質を高めることで、デリバリーが高速になることが多い。
  • 品質基準を下げてしまうと、デリバリーが遅くなり、予測できなくなってしまう。

ラクティス

ラクティスとは、チームが日常的に行うものです。 単独でも機能しますが、組み合わせた方がより機能します。 すぐに改善につながり、どれからでも始められる「主要プラクティス」と、先に主要プラクティスを習得しておかなければ難しいであろう「導出プラクティス」について書いてありました。 この記事では「主要プラクティス」について紹介します。

チーム全体

  • プロジェクトの成功に必要なスキルや視点を持った人たちをチームに集めること。
  • プロジェクトの健全性のために綿密なやりとりが必要なところでは、機能単位ではなく、チーム単位でやりとりをすること。
  • そのためには、以下のような「チーム」感が必要。
    • 我々は、帰属している。
    • 我々は、一緒の仲間である。
    • 我々は、お互いに仕事、成長、学習を支えている。
  • 「チーム全体」の構成要素は動的に変化する。
    • スキルや考え方が重要なときには、それを身に付けた人をチームに迎え入れればいい。
    • 必要なくなれば、チームから外れてもらえばいい。
    • プロジェクト単位でメンバーを動的に変更してもいい。

いきいきとした仕事

  • 生産的になれる時間だけ働くこと。
  • 無理なく続けられる時間だけ働くこと。
  • 意味もなく燃え尽きてしまい、次の2日間の作業が台無しになることは、自分にとってもチームにとってもいいことではない。
  • ソフトウェア開発は洞察力のゲーム。洞察力は、準備の整った、休息のとれた、リラックスした精神から生み出される。
  • その他の方法では制御不能になったときに、制御を取り戻す手段として、長時間労働することが多い。
  • だが、疲労した状態では、バリューを奪っていることさえ気づかない。
  • 病気のときは休息と回復に努め、自分とチームをリスペクトすること。静養こそがいきいきとした仕事に戻る近道。

ペアプログラミング

  • 同じマシンを前にした2人でプログラムを書くこと。
  • ペアプログラミングでやること。
    • お互いにタスクに集中する。
    • システムの改良について意見を出し合う。
    • イデアを明確にする。
    • パートナーがハマったら主導権を握り、相手の失望感を軽減させる。
    • お互いにチームのプラクティスの説明責任を果たせるようにする。
  • ペアプログラミングは満足感はあるが、実際にやると疲れるプラクティス。
  • 休息を挟めば、新鮮な気持ちを一日中保つことができる。
  • うまくやるには、お互いのパーソナルスペース、個人差をリスペクトすることが重要。

ゆとり

  • どのような計画にも、遅れたときに外せるような重要度の低いタスクを含めること。
  • 少しでもやるべきことを果たせば、人間関係の再構築につながるはず。
  • 明確で正直なコミュニケーションは信頼を高める。

インクリメンタルな設計

  • システムの設計に毎日手を入れること。
  • システムの設計は、その日のシステムのニーズにうまく合致させること。
  • 最適だと思われる設計が理解できなくなってきたら、少しずつだが着実に、自分の理解できる設計に戻していくこと。
  • 欠陥の修正コストは時間の経過によって指数関数的に増加することが示されている。
  • 設計に毎日注意を払わなければ、変更コストは急増する。その結果、設計が貧弱で脆弱な変更しにくいシステムになってしまう。
  • シンプルで役に立つ解決策は、重複を排除すること。
  • 重複のないコードは変更しやすい。
  • インクリメンタルな設計は、使用する直前に設計するのが最も効率的。
  • そうすれば、システムはシンプルになり、進捗は早くなり、テストが書きやすくなる。システムが小さくなるので、チームのコミュニケーションも軽減できる。

おわりに

スクラム開発と比較すると、XP はより技術的内容にフォーカスしているように思いつつも、原則やプラクティスからは人間性を大切にする考え方が根底にあると感じました。 ソフトウェア開発は人間が行うものであり、またそれを使うのも人間です。 良いものを作ってエンドユーザーの幸福に寄与するためにも、まずは私たちがコンディションを整えたり社会的欲求を満たすことで、自分らしくいられる環境づくりが重要だと思います。 本書で学んだことを取り入れ、スクラムマスターとしてより良い環境づくりを目指したいです。

地方在住エンジニアが上京して変わったこと:技術イベント参加を通じて得た経験

この記事は個人ブログと同じ内容です


はじめに

私は、新潟に住みながらフルリモートでエンジニアとして働いていました。その理由の一つは、男子新体操の練習を続けるためです。しかし、2022年の冬頃からエンジニアのイベントに参加したいという気持ちが高まっていました。地方にいると、なかなかその機会を得るのは難しく、実際に参加しないまま終わってしまうことが多かったのです。このままでは一生イベントに行かないままで終わってしまうと思い、関東に拠点を移してみることにしました。そして、いくつかの技術イベントに参加してみることにしました。

この記事では、地方から上京したエンジニアが経験した変化について、特に技術イベントに参加した際の感想や学びについてお話ししたいと思います。

これまでに参加したイベント

関東に拠点を移してから参加したイベント(1月〜4月)は以下の通りです。

これらのイベントには、参加者として、当日スタッフとして、そして登壇者として、すべての役割で参加しました。私の目的は、登壇者の話を聞くというよりは、交流を目的としていました。

参加者としての経験

参加者としてイベントに参加する場合、一人だと懇親会で自分から話しかけに行く勇気が必要です。しかし、それができる人にとっては、非常に効率的(タイパ)でおすすめです。自分の興味のある分野やテーマに対して、直接情報を得たり、意見を交わしたりすることができるため、多くの刺激を受けることができます。

当日スタッフとしての経験

OOCに参加するときに、チケットが売り切れてて、当日スタッフだと参加できたのでやりました。 当日スタッフとして参加すると、同じ作業をする仲間がいるため、自然と多くの人と関わることができます。そのため、交流しやすく、新たなつながりを作りやすい環境が整っています。特に、参加者同士だけでなく、登壇者やイベントの主催者とも接点が持てるため、非常に貴重な経験になります。

登壇者としての経験

イベントに参加していくうちに、2024年中に1回発表できたらいいなと思ってた時に、エンジニアの友達に誘われてLTをやりました。 登壇者として発表することは、非常に大きな学びの場となります。発表者同士での交流が生まれたり、参加者から声をかけてもらえることが多く、エンジニアとしての視野が広がります。もちろん、発表自体は大変ですが、その分得られるものも多いです。

発表したLT↓ @speakerdeck

発表における課題と学び

私が登壇した際はLT(ライトニングトーク)形式だったので、短い時間でわかりやすく伝えることの難しさを感じました。発表資料を作成する際、間違った情報を伝えたくないという思いから、関連する内容を深く調べることになりました。これは良い学習の機会となりました。

私の発表では技術の深い部分には触れませんでしたが、それでも準備には時間と労力がかかりました。もっと深い内容を扱う場合、さらに多くの準備が必要だと感じました。

プロジェクトに対する主体性の向上

技術イベントでの発表を通じて、プロジェクトに対する主体性が向上しました。話題を持って行った方が会話に困らないため、自分のチームやプロダクトの課題を話す機会が増えました。その結果、自分のプロダクトやチームに対する課題感を持ちやすくなり、改善点を具体的に考えるきっかけとなりました。

イベントに参加して得られたこと

技術イベントに参加することで、さまざまなエンジニアと関わりを持つことができました。これにより、他社の状況を知ることができたり、優秀なエンジニアが何を考えているのかを知ることができ、非常に刺激を受けました。

また、言語化能力も向上しました。自分の考えを整理し、他者に伝えるためのスキルが必要とされる場面が多かったため、自然とこの能力が鍛えられました。

結論

地方から上京してエンジニアとしての活動を広げることは、新たな出会いや学びの機会を増やす大きな一歩となりました。技術イベントに参加することで、単なる情報の受け取り手ではなく、主体的にコミュニティに関わることができるようになりました。

もし、地方に住んでいるエンジニアの方で、技術イベントに興味があるけれど参加を迷っている方がいるなら、一度関東に足を運んでみることをお勧めします。きっと、新しい世界が広がるはずです。

【ローカルで動作確認】Functions Framework を用いた Cloud Functions 開発

この記事は個人ブログと同じ内容です

www.ritolab.com


Functions Framework を用いた Cloud Functions 開発

Google Cloud Functions は、サーバーレスコンピューティングの強力なソリューションです。Functions Framework を使用することで、開発者はローカル環境で Cloud Functions を効率的に開発、テスト、デバッグすることができます。本記事では、Functions Framework を用いた Cloud Functions 開発の基本的な流れと、実際の実装方法について解説します。

Functions Framework の主な利点は以下の通りです:

  1. ローカル環境での迅速な開発とテスト
  2. 本番環境との一貫性の確保
  3. 複数の言語とランタイムのサポート
  4. オープンソースで柔軟なカスタマイズが可能

これから、Functions Framework のセットアップから、HTTP トリガーとイベントトリガーの関数の実装、そしてローカルでの動作確認までの手順を詳しく見ていきます。この記事を通じて、Cloud Functions の開発プロセスをスムーズに進められるようになることを目指します。

開発の流れ

Functions Framework を用いた CloudFunctions 開発の流れは以下になります。

  1. 関数の実装
  2. ローカルサーバー起動(TypeScript で実装する場合は起動前にビルド)
  3. 関数の実行(動作確認)

Functions Framework の導入

Functions Framework をインストールします。

pnpm add @google-cloud/functions-framework

TypeScript で実装する前提ですが、package.json は以下の状態になっています。

package.json

{
  "dependencies": {
    "@google-cloud/functions-framework": "^3.4.1"
  },
  "devDependencies": {
    "@types/node": "^20.14.10",
    "typescript": "^5.5.3"
  }
}

参考: Functions Framework を使用して関数を実行する - Google Cloud

ビルドとローカルサーバ起動の設定

CloudFunctions 関数をローカルで実行できるようにするために、ビルドとローカルサーバ起動の設定を行っておきます。

tsconfig.json

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2022",
    "strict": true,
    "outDir": "./dist"
  },
  "include": [
    "src"
  ]
}

package.json の script フィールドに以下を記述します。

package.json

{
  "scripts": {
    "build": "tsc",
    "start": "functions-framework --target=helloWorld --source=dist",
    "start:dev": "npm run build && npm run start"
  },
  "dependencies": {
    "@google-cloud/functions-framework": "^3.4.1"
  },
  "devDependencies": {
    "@types/node": "^20.14.10",
    "typescript": "^5.5.3"
  }
}

pnpm run start で、functions-framework コマンドを用いてローカルサーバを起動しています。

TypeScript で実装したソースコードを js ファイルにビルドし、それを実行する流れになるため、pnpm run start:dev でビルドとローカルサーバの起動を一度に行っています。

CloudFunctions 関数の実装と動作確認

では CloudFunctions 関数を実装し、ローカルで動作確認を行ってみましょう。

HTTP トリガー

まずは HTTP トリガーで実装してみます。

src/index.ts

import * as functions from '@google-cloud/functions-framework'

functions.http('helloWorld', (req: functions.Request, res: functions.Response) => {
    res.send('Hello, World');
})

実装したら動作確認です。以下コマンドでローカルサーバを起動します。

pnpm run start:dev

# % pnpm run start:dev
# 
# Serving function...
# Function: helloWorld
# Signature type: http
# URL: http://localhost:8080/

HTTP トリガーでローカルサーバが起動しました。続いて、別のターミナルからエンドポイントへリクエストを送信してみます。

% curl localhost:8080
Hello, World

CloudFunctions 関数をローカルの開発環境で実行できました。

参考: HTTP 関数を作成する - Google Cloud

イベントトリガー

次に、イベントトリガーでも実装してみます。

src/index.ts

import * as functions from '@google-cloud/functions-framework'

functions.cloudEvent('helloWorld', cloudEvent => {
    console.log('Hello, World')
})

再度、ローカルサーバを起動します。

pnpm run start:dev

# % pnpm run start:dev
# 
# Serving function...
# Function: helloWorld
# Signature type: cloudevent
# URL: http://localhost:8080/

イベントトリガーでローカルサーバが起動したことがわかります。続いて、別のターミナルからエンドポイントへイベントリクエストを送信してみます。

curl localhost:8080 \
  -X POST \
  -H "Content-Type: application/json" \
  -H "ce-id: 123451234512345" \
  -H "ce-specversion: 1.0" \
  -H "ce-time: 2024-07-15T10:11:10.789Z" \
  -H "ce-type: google.cloud.storage.object.v1.finalized" \
  -H "ce-source: //storage.googleapis.com/projects/_/buckets/my-bucket" \
  -H "ce-subject: objects/my-file.txt" \
  -d '{
    "bucket": "my-bucket",
    "contentType": "text/plain",
    "kind": "storage#object",
    "md5Hash": "...",
    "metageneration": "1",
    "name": "my-file.txt",
    "size": "352",
    "storageClass": "MULTI_REGIONAL",
    "timeCreated": "2024-07-15T10:11:10.789Z",
    "timeStorageClassUpdated": "2024-07-15T10:11:10.789Z",
    "updated": "2024-07-15T10:11:10.789Z"
  }'

ローカルサーバーを起動したターミナル側に Hello, World が出力され、関数が実行されたことがわかります。

参考: イベント ドリブン関数を作成する - Google Cloud

まとめ

本記事では、Functions Framework を用いた Cloud Functions 開発の基本的な流れと実装方法について解説しました。主なポイントは以下の通りです:

  1. Functions Framework の導入とセットアップ
  2. TypeScript を使用した開発環境の構築
  3. HTTP トリガーとイベントトリガーの関数実装
  4. ローカル環境での動作確認方法

Functions Framework を活用することで、開発者は以下のメリットを享受できます:

  • ローカル環境での迅速な開発サイクルの実現
  • 本番環境との一貫性を保ちながらのテストと検証
  • デプロイ前の問題の早期発見と修正

Functions Framework は、効率的で信頼性の高い Cloud Functions 開発をサポートする強力なツールです。ローカルでデバッグできれば開発スピードも格段に上がります。ぜひ試してみてください。

Functions Framework - Google Cloud

Looker Studio で Cloud Billing データ(料金・コスト)を可視化する

この記事は個人ブログと同じ内容です

www.ritolab.com


GCP コスト管理の重要性と可視化の必要性

クラウドコンピューティングの普及に伴い、多くの企業が Google Cloud Platform (GCP) を利用しています。しかし、クラウドサービスの利用が拡大するにつれて、コスト管理の重要性も増しています。効果的なコスト管理は、ビジネスの収益性と持続可能性に直接影響を与える重要な要素です。

GCP の課金システムは柔軟で詳細ですが、その複雑さゆえに、実際の使用状況と費用を把握することが困難な場合があります。特に、複数のプロジェクトや多様なサービスを利用している場合、全体像を把握することは容易ではありません。

そこで重要になるのが、コストデータの可視化です。

データを視覚的に表現することで、以下のような利点が得られます:

  1. 費用の傾向を素早く把握できる
  2. 異常な支出を迅速に発見できる
  3. リソースの最適化の機会を特定しやすくなる
  4. 部門間や経営陣とのコミュニケーションが円滑になる

本記事では、GCPの課金データを Looker Studio を使って可視化する方法を詳しく解説します。この方法を実践することで、データドリブンなコスト管理が可能となり、クラウド利用の最適化につながります。

それでは、具体的な手順を見ていきましょう。

BigQuery にデータセットを作成

まずは、Cloud Billing から BigQuery にデータをエクスポートするためのデータセットを作成します。

作成するデータセットは全部で 3 つです。データセット名は任意の名前で問題ありません。

データセット 用途
billing_standard 標準使用料金データ用
billing_detail 詳細使用料金データ用
billing_dashboard_views ビューテーブル用

それぞれのデータセットの中には、以下の形式を持ったパーティション分割テーブルが作成されます。

  • billing_standard
    • gcp_billing_export_v1_<BILLING_ACCOUNT_ID>
  • billing_detail
    • gcp_billing_export_resource_v1_<BILLING_ACCOUNT_ID>

請求アカウント別にテーブルが出来上がるようですね。

BigQuery の Cloud Billing データテーブルについて - Google Cloud

課金データをエクスポートする

GCP コンソール画面の「課金データをエクスポート」から、「標準の使用料金」「詳細な使用料金」それぞれに、作成したデータセットを指定します。

この設定を行うと、翌日ないし翌々日から Billing データが BigQuery へエクスポートされてくるようになります。

今回の例でいうと、データセット billing_standard と billing_detail にテーブルが作成されデータ入ります。

BigQuery への Cloud Billing データのエクスポートを設定する - Google Cloud

ちなみに、ここでエクスポートを有効にした日以降に発生した Google Cloud の使用量と費用のデータが BigQuery へ反映されます。過去のものは入りません。

Looker Studio: 課金利用状況と費用に関する分析情報のダッシュボード

Looker Studio で Google Cloud の費用情報を可視化していくにあたり、GCP の方で既にダッシュボードが公開されているので、こちらを使用していきます。

課金利用状況と費用に関する分析情報のダッシュボード - Google Cloud

GCP Professional Services

この、公開されているダッシュボードを、エクスポートした私たちのコスト情報に置き換えて新たに自分のダッシュボードを作成していきます。それには以下のツールを使用します。

GoogleCloudPlatform/professional-services - GitHub

このリポジトリは、Google Cloud のプロフェッショナルサービスチームが開発したツール、スクリプト、およびベストプラクティスのコレクションです。このリポジトリは、ユーザーが Google Cloud Platform (GCP) 環境を効果的に実装、管理、最適化するのを支援することを目的としています。

ここで提供しているツールの 1 つに、今回のダッシュボードを自分のデータにアタッチして新たなダッシュボードを作成できるスクリプトがあります。

ダッシュボード作成

では Looker Studio にダッシュボードを作成していきます。

Professional Services のスクリプトを使用するために、Cloud shell を使います。

Cloud Shell を利用して、Professional Services の GitHub リポジトリを clone します。

Cloud Shell で GitHub リポジトリを clone する(実際にあなたの GCP 環境へ遷移し Cloud Shell を開きます)

上記 URL へアクセスすると、以下の確認モーダルが表示されるので、「確認」を押下します。

環境構築が開始されるのでしばし待ちます。

Cloud Shell の環境構築が完了すると、Professional Services リポジトリをクローンした状態で Cloud Shell Editor が起動します。

この画面の下半分にある cloud shell コンソールに、以下のコマンドを順番に入力し、実行していきます。

# 1. 移動
cd examples/billboard

# 2. bill-env が既に存在する場合は削除
rm -rf bill-env

# 3. virtualenv をインストール
pip3 install virtualenv

# 4. 仮想環境を作成
virtualenv bill-env

# 5. 仮想環境をアクティベート
source bill-env/bin/activate

# 6. 必要なパッケージをインストール
pip3 install -r requirements.txt

# 7. ダッシュボード作成スクリプトを実行
python3 billboard.py \
  -pr '<<YOUR_PROJECT_ID>>' \
  -se 'billing_standard' \
  -de 'billing_detail' \
  -bb 'billing_dashboard_views'

7 つ目のコマンドを実行すると Looker Studio にダッシュボードが作成され、レポートの URL が Cloud Shell に出力されるので、これをクリックします。

これで、請求情報のダッシュボードを作成することができました。最後に、このダッシュボードを保存することで、継続的に請求情報を Looker Studio から確認できるようになります。

数日経過後

まとめ:Looker Studioで効果的なGCPコスト管理を実現

本記事では、Google Cloud Platform (GCP) の課金データを Looker Studio で可視化する方法について解説しました。主なポイントは以下の通りです:

  1. BigQuery にデータセットを作成し、Cloud Billing からデータをエクスポート
  2. Google 提供の「課金利用状況と費用に関する分析情報のダッシュボード」テンプレートを活用
  3. GCP Professional Services のツールを使用して、自身のデータに適用したダッシュボードを作成

この方法を実践することで、以下のメリットが得られます:

  • GCP の利用コストを視覚的に把握できる
  • 課金データは定期的に自動更新され、費用の推移を確認できる
  • プロジェクトやサービスごとの詳細な費用分析が可能

コスト管理は、クラウドサービスを効率的に利用する上で非常に重要です。Looker Studioを活用することで、データドリブンな意思決定が可能となり、最適なリソース配分やコスト削減の機会を見出すことができます。

とはいえ、GCP が提供するサービスは多岐にわたるため、1 から自分で請求情報のダッシュボードを作成するのは本当に手間がかかります。今回は Professional Services が提供しているスクリプトを利用し、公開されているレポートレイアウトを使用しましたが、こういったところも予め用意されているのは非常にありがたいです。

定期的にダッシュボードを確認し、必要に応じて最適化を行うことで、GCP の利用をより効果的かつ経済的なものにすることができると思います。是非試してみてください。

Looker Studio を使用して費用を可視化する - Google Cloud

IntelliJ + DevContainer + Zenn CLI でブログ執筆環境を構築する

この記事は個人ブログと同じ内容です


はじめに

この記事では、IntelliJ IDEA と DevContainer, Zenn CLI を利用してブログ執筆環境を構築する方法をご紹介します。

DevContainer とは

以下が参考になりました。

Devcontainer とは、 Dockerコンテナを開発環境とし作成することで、開発環境に必要なライブラリやランタイムのバージョン、Extension をコンテナ内に閉じ込めその中で完結させることができます。

  • Dockerコンテナ内に開発で必要なものをすべて閉じ込める ⇒ ローカル環境を汚染しない
  • コマンドで構築終わり ⇒ 開発環境の構築が楽になる
  • 構築時のヒューマンエラー発生率低減 ⇒ システムのコード化

Zenn CLI とは

ローカルの好きなエディターで Zenn の投稿コンテンツを管理・プレビューするためのツールです。

前提条件

コンテナを作成する

リポジトリをクローンする

作成済みの GitHub リポジトリをクローンします。

Dev Container テンプレートを選択する

  1. IntelliJ のエディターでクローンしたリポジトリを開きます。
  2. プロジェクトのトップディレクトリで、⌘ + N を押下して新規ファイル作成ダイアログを開きます。
  3. .devcontainer を選択します。
  4. 「Dev Container テンプレート」フィールドを選択して、「node」と入力し、検索結果から「Basic Node.js」を選択します。
  5. 今回タグは 20-bookworm-slim を選択します。
    • 20 = Node.js のバージョン。Zen CLI は Node.js 14 以上が必要です。
    • bookworm = Debian のコードネーム。
    • slim = 使用頻度の低いパッケージが除外された軽量なイメージ。

  6. 「OK」ボタンを押下すると、.devcontainer ディレクトリが作成され、devcontainer.jsonDockerfile が作成されます。

devcontainer.json を編集する

自動で生成された devcontainer.json は以下のようになっています。

{
   "name": "Basic Node.js",
   "build": { "dockerfile": "Dockerfile" },
   "remoteUser": "node",
   "customizations" : {
      "jetbrains" : {
         "backend" : "WebStorm"
      }
   }

}

以下のように編集します。

{
  "name": "Zenn Workspace", // 一覧に表示される DevContainer 名
  "build": {
      "dockerfile": "Dockerfile"
  },
  "remoteUser": "zennwriter",
  "runArgs": ["--name", "zenn_workspace"], // 任意の Dcoker コンテナ名を指定
  "customizations" : {
    "jetbrains" : {
      "backend" : "PhpStorm" // 利用したい IntelliJ のエディター
    }
  },
   "mounts": [
      "source=${localEnv:HOME}${localEnv:USERPROFILE}/.ssh,target=/home/zennwriter/.ssh,type=bind,consistency=cached,readonly" // devcontainer 内で GitHub に push するため SSH 設定をマウント
   ]
}

Dockerfile を編集する

自動で生成された Dockerfile は以下のようになっています。

FROM library/node:20-bookworm-slim

ARG DEBIAN_FRONTEND=noninteractive
RUN apt update \
    && apt install -y --no-install-recommends sudo \
    && apt autoremove -y \
    && rm -rf /var/lib/apt/lists/* \
    && echo "node ALL=(ALL) NOPASSWD: ALL" >/etc/sudoers.d/node \
    && chmod 0440 /etc/sudoers.d/node

そのまま起動すると以下のエラーが発生しました。

Cannot find required dependencies in dev container: ps

どうやら必要なパッケージの一つである ps がインストールされていないため、エラーが発生しているようです。 procps パッケージをインストールすることで解決しました。 ユーザー作成や言語設定なども追加して、編集後の Dockerfile は以下のようになりました。

FROM node:20-bookworm-slim

ARG USERNAME=zennwriter
ARG USER_UID=1001
ARG USER_GID=$USER_UID

ENV LANG ja_JP.UTF-8
ENV LANGUAGE ja_JP:ja
ENV LC_ALL ja_JP.UTF-8
ENV TZ Asia/Tokyo

RUN groupadd --gid $USER_GID $USERNAME \
    && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \
    && apt update \
    && apt install -y --no-install-recommends sudo procps locales git vim ca-certificates \
    && apt autoremove -y \
    && sed -i -e 's/# \(ja_JP.UTF-8\)/\1/' /etc/locale.gen \
    && locale-gen \
    && ln -sf /usr/share/zoneinfo/$TZ /etc/localtime \
    && rm -rf /var/lib/apt/lists/* \
    && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \
    && chmod 0440 /etc/sudoers.d/$USERNAME

USER $USERNAME

コンテナを起動する

  1. devcontainer.json を開いている状態で、左側の青くて四角いアイコンを押下します。
  2. ダイアログが表示されるので、「Create Dev Container and Mount Sources」を選択します。
    • 「Create Dev Container and Clone Sources」の方が処理速度が早いため公式はこちらを推奨しているようですが、今回は個人ブログ用のため他の人と環境を共有する機会がないこと、devcontainer に変更があった場合 GitHub を介さずにすぐ反映できるようにするため、Mount Sources を選択しています。

  3. 「Environment prepared」と表示されることを確認します。
  4. デフォルトでは EAP (Early Access Program = 開発中のベータ版) のエディターが選択されているので、好みで変更します。
  5. 「Continue」ボタンを押下して、コンテナを起動します。
  6. 新しくエディターが開いたら起動完了です。

Zenn CLI をインストールする

新しく開いたエディターでターミナルを開き Node.js がインストールされていることを確認します。

$ node -v
# v20.14.0

公式のインストール方法に従って Zenn CLI をインストールします。

$ npm init --yes # プロジェクトをデフォルト設定で初期化
$ npm install zenn-cli # Zenn CLI を導入
$ npx zenn init # Zenn CLI を初期化
$ npx zenn preview # プレビューを起動

ターミナルのポート番号を押下し、Open in Browser を選択した後に、ブラウザでプレビューが開いたら Zenn CLI のインストールは成功です。

Zenn と GitHub リポジトリを連携する

GitHubリポジトリと連携することで、ローカルで記事を書いてそのまま投稿することができます。 導入方法は公式の手順をご覧ください。

おわりに

Zenn の執筆環境を構築する方法をご紹介しました。

普段 PhpStorm を利用しているため、慣れた設定やショートカットキーで環境構築したくて今回書いたのですが、VS Code の記事が多く IntelliJ の情報は少なくて苦戦しました。また IntelliJ の DevContainer は現在 Beta 版のため、ある程度の規模の開発プロジェクトで DevContainer を利用する場合は、VS Code と仲良くなった方がいいなと感じました。

とはいえ、ブログの環境構築程度でしたら IntelliJ でも十分だと思います。 DevContainer を使うことでローカル環境を汚さずに環境を構築できるので、ぜひ自分の好みに合わせてカスタマイズしてみてください。

男子新体操とはエンジニアリングである

この記事は個人ブログと同じ内容です


はじめに

私はエンジニアであり、男子新体操というスポーツをやっており、プライベートの時間に練習し、大会に出場してたりします。 私は個人競技をやっており、飽き性なため、4種目の演技を毎年作り変えています。 ※一般的には1つの演技を作ったら2~3年、長い人は7年ほど同じ演技をします

エンジニアを仕事としてやっていくうちに、男子新体操での演技作りと似ている部分が多いと、かなり前から感じていたので、面白いと思ってこの記事を書いてみました。

男子新体操とは

団体

youtu.be

個人

youtu.be

ダンスとアクロバットを混ぜたようなスポーツで、団体は6人で行い、個人は1人で4種目(スティック、リング、ロープ、クラブ)を行うスポーツです。 女子の新体操とは全く異なり、女子は華麗なスポーツであるのに対して、男子新体操はダイナミックで迫力があり、カッコいいスポーツです。 日本発祥で日本のみで、行われているスポーツです。

男子新体操のルール

  • 20点満点の減点方式
  • クロバット3回や投げの回数など、最低限のルールはあるがその他は自由
  • トリッキングやバレエ、ダンスなどのほか競技の技を入れても良い

男子新体操だけではなく、クリエイティビティを必要とするスポーツ全般に言えることですが、 100点の演技は存在しないので、曲を変えたり動きを変えたりして、無限に遊ぶことができるスポーツです。

答えのない不確実なものを試行錯誤し、形にしていくという点では、スポーツもビジネスも考え方は同じだと思いました。

演技(プロダクト)作りのやり方

私は以下の流れで演技作りをやっています。

市場調査 → 全体案を考える → 小さく作っていく → 全体で合わせる → 改修

私の場合は、新しいものを作るのではなく、上手い人のを盗んで、それを組み合わせて演技を作っていきます。 新しいものではなく、既存のものを組み合わせたり、プラスしていって作る感じです。 これは新しいビジネスアイディアを考える時と全く同じです。

市場調査

男子新体操は毎年レベルアップしているので、昔の演技をやっても点数が出るわけではなく、その年によって求められるものが変わってきます。 なので、はじめに前年の人の演技を見たり、審判からの聞き込み調査をして、どんな傾向があるかを調査します。

全体案考える

市場調査をもとに、ざっくり演技全体を作っていきます。 曲をベースに演技を作るので、曲を聴き、どこにどの動きをハメたいか、全体の動きの流れなどをざっくり決めます。

小さく作っていく

全体案をもとに、演技を4分割して、それぞれのパートを作っていきます。 それらを組み合わせて、全体感を見て違ったら、減点項目になりそうなものや違和感のある部分を直します。 ある程度の演技ができたら一旦完成です。

ここで意識しているのは、 最初から完璧なものを作らないし、求めない ということです。 自分が良くても、他の人から見ると違和感があるなど、演技には不確実要素が多いので、 私の場合、「音に合う、ある程度の流れが良い」という 最低限の要件を満たしたMVP(Minimum Viable Product)を作っていきます。

最低限の演技ができたら、 人のアドバイスや、もっと良くなりそうなポイントを練習で探し、それを元に演技を無限に改善していきます。

エラーハンドリングを考える

投げを落とした時などのミスをした後に、演技に影響が出ないように、そのパターンも想定して演技を作っています。 事前に復旧しやすい可用性の高い演技設計を意識しています。

最後に

この記事で語ったことは、あくまで私の場合なので、他の人の作り方は知りませんし、違っている可能性があります。 全日本大会で上位のチームたちは、私と違い、常に新しいものを開発し、取り入れてます。 この記事を通して少しでも男子新体操というスポーツを理解してもらえたら嬉しいです。


現在 back check 開発チームでは一緒に働く仲間を募集中です。 https://herp.careers/v1/scouter/j25fiAusU1v1herp.careers