GCP

あけましておめでとうございます。本年はアウトプットの数を増やすという目標のもと、さっそくブログの更新をする。 年末年始は友人・家族と会えたし、飲みすぎないようにしたおかげで溜まってた本の解消やBLEACH全巻読んだりと充実できた。 去年、学んだk8sのGateway APIについて記事を書く。 Gateway APIとは Gateway APIは動的なインフラストラクチャの展開と高度なトラフィックルーティングを提供するAPIの種類のファミリーです。 とのこと。これだけだとわかりにくいが、要はk8sへの通信を担うLBをコード化して自動管理しようっていう認識であっていると思う。詳しくは、以下リンクでk8sやGCPの公式ドキュメントをみると理解が深まると思う。特に、GCPのドキュメントは具体的にどのリソースと紐づくのがわかりやすいので、GCPを知っている人はこっちを読むのをおすすめする。 https://kubernetes.io/ja/docs/concepts/services-networking/gateway/ https://docs.cloud.google.com/kubernetes-engine/docs/concepts/gateway-api?hl=ja きっかけ 学んだきっかけは、会社でGKE StandardからAutopilot移行をしたときに、Autopilotクラスタが利用可能なすべてのゾーンにNEGが作成されていない状態で、手動でLBを作成すると障害になるケースがある。 という事象を発見したから。移行時の話は以下リンクから見れるので興味ある方は見てほしい。 所属している会社のアドベントカレンダーを書いた2025 さわってみた Gateway APIはk8sのマニフェストファイルを増やすことで実装できる。 kustomizeを利用する前提でディレクトリ構成を以下に記載する。GCPの場合は、LB作成時に必要なフロント、バック、ヘルスチェック、バックに登録するNEGをそれぞれ表現しているイメージを持ってもらうのがわかりやすそう。 また、GKEのPodでNginxを立てている想定でサンプルは実装している。 k8s/ └── base/ ├── configmap.yaml ├── deployment.yaml ├── gateway.yaml ├── healthcheck.yaml ├── httproute.yaml ├── kustomization.yaml └── service.yaml Gateway APIに関係している実装は、gateway.yaml, healthcheck.yaml, httproute.yaml, service.yamlなので、それぞれサンプル実装を記載して解説をする。 gateway.yaml kind: Gateway では利用するLBの種類やトラフィックをリッスンする場所と方法などの設定ができる。 addressesは予約したIPを指定して利用することもできる。 apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: nginx namespace: default spec: gatewayClassName: gke-l7-rilb # Regional Internal Load Balancer listeners: - name: http port: 80 protocol: HTTP allowedRoutes: namespaces: from: All addresses: - type: NamedAddress value: nginx healthcheck.yaml これはLB作成時に必要なヘルスチェック。 ...

久しぶりの投稿です。 ここ数年は広い領域の仕事をしていて、結構インプットができました。 アウトプットが少ないなと毎回思うので、ちょっとしたことでもいいのでブログ更新しようと思います。 継続って難しい。。 アドベントカレンダー書いた ということでQiitaのアドベントカレンダーを書いたのでURL載せておきます。 GKE StandardからAutopilotへの移行 Google CloudのGKE関連やネットワークには知見を貯めれました。こういったところの学びやハマりポイントなど記事にできるとよさそうかなと思っています。 あとは気分的に本ブログのドメインをサブドメでblog.yuyagishita.comにしたいかなと思っています。

Journalというジャーナリングをするアプリをリリースしました。 ジャーナリングとは自分が思っていることを書き出すことで自分について理解を深めたり、自分がやりたいことを見つけるのに役立ったりします。 日記をイメージしてもらうのがわかりやすいと思います。 今回はJournalを支えている技術について紹介します。 フロントエンド Next.js フロントエンドはNext.js（React）とTypeScriptを使っています。 なるべくシンプルに作りたかったので全ページをSPAで作っていますが、SSGできそうなところはSSGを使って静的ファイルにしたいと思ってます。 Tailwind CSS CSSにはTailwind CSSを使っています。Next.jsとの相性が良さそうだったのとシンプルで使いやすそうだと思って選びました。CSSの知識が乏しいのでネットの有識者を参考にした結果、Tailwind CSSにしました。 Vercel フロントエンドの本番環境のデプロイ先にはVercelを使っています。 VercelはNext.jsの運営元でデプロイがとても簡単で使いやすかったので選びました。 GitHubのリポジトリを指定すれば自動でデプロイをしてくれますし、設定も少なめで本当に簡単です。 Vectr サイトのロゴやファビコンを作るのにVectrを使っています。Vectrはsvg形式のファイルを無料で作れるので利用しました。 バックエンド Echo バックエンドはGoのフレームワークであるEchoを使っています。 GoでAPIを作るのにEchoはとてもお手軽とのことだったので選びました。 アーキテクチャにはクリーンアーキテクチャを選んでいます。クリーンアーキテクチャでコードを書いたことがありませんでしたが、テストコードが書きやすかったり、外部のライブラリなどの依存が減るので採用してよかったなと思っています。 また、コード量が増えたことはデメリットかなと思います。 Cloud Run バックエンドの本番環境のデプロイ先はCloud Runを使っています。 ローカルの開発環境でDockerを利用していて同じようなDockerfileでCloud Runにデプロイができ、Cloud Runがいい感じにリクエストをさばいてくれます。 ただ、アプリが起動するまでに10秒弱ぐらい時間がかかってしまいAPIのレスポンス待ちになってしまうのがデメリットかなと思います。Cloud RunはフルマネージドでAPIを叩かれていないときはコンテナが起動していないのでレスポンスに少し時間がかかってしまうのは仕方ないですね。 Cloud SQL データベースの本番環境はCloud SQL(PostgreSQL)を使っています。 普段の仕事でも使っているRDBが自分としては使いやすいの選びました。 その他に利用しているサービス GitHub Actions CI/CDツール。バックエンドのデプロイに使っています。 Firebase Authentication ログイン認証のため。 Google Domains ドメイン取得のため。なるべくGCPにサービスを寄せている。