この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
MADグループ@福岡 の 田中孝明 です。 7/21 に開催した AKIBA.MAD 「Google Cloud で実現するモダンアプリケーション開発」のまとめになります。
動画
※10/18 までの期間限定公開になります。
最新アップデート情報 （Issei Hiraoka さん）
Serverless (Cloud Run / Cloud Functions)
- Cloud Run の 第 2 世代について
- 性能の高速化
- CPU パフォーマンスの高速化
- ネットワークパフォーマンスを高速化
- ユースケースの拡大
- Linux との完全な互換性
- ネットワークファイルシステムのサポート
- プレビュー段階では第一世代よりもコールドスタート時間が長くなることに注意
- 使い勝手の幅が広がる
- 性能の高速化
- Cloud Functions の第 2 世代について
- 第 2 世代の環境が選択可能に
- Cloud Run の実行基盤で Cloud Functions が動く
- 今までの Cloud Functions（第 1 世代）の課題
- 実行環境に、同時実行性がない、呼び出し毎に別の実行環境が起動される
- 長時間の処理を実行する際の制限(最長 10 分でタイムアウト)
- 現在のバージョンと次のバージョンでトラフィック分割する、といった柔軟な トラフィック制御は不可
- Cloud Functions の第 2 世代でより高機能に
- Cloud Run と Eventarc を基盤としたアーキテクチャ
- 同時実効性の実現
- コスト最適化
- 一貫したデータ形式
- Cloud Run と Eventarc を基盤としたアーキテクチャ
- Cloud Run と Cloud Functions の使い分け
- Cloud Run が良いケース
- 複数サービスの連携
- 一定規模のシステムをサーバーレスで構築
- Cloud Functions が良いケース
- Cloud Functions の単位は「関数」
- Workflows を併用した、一連のワークフロー作成
- 3rd パーティとの連携
- Google Cloud プロダクト間をつなぐような処理
- Cloud Run が良いケース
- Cloud Run jobs
- Cloud Run で、バッチ処理などを行うための機能で第 2 世代でのみ利用可能
- 従来の Cloud Run との違い
- HTTP リクエストに依らない実行
- 長時間の実行 (複数の Task を組み合わせて 60 分以上の実行を実現)
- 明示的な並列処理
- Cloud Run jobs のリソースモデルについて
Cloud Operations
- Cloud Run の SLO モニタリングについて
- SLO モニタリング
- 顧客にサービスの可用性がどのくらい担保できているかなどをみれるように
- SLO モニタリング
- Google Cloud Managed Service for Prometheus (GMP)
- Prometheus のマネージドサービス
- 既存の問題
- 監視の仕組みの監視をしなくちゃいけなかった手間があった
Google Cloud Managed Service for Prometheus
- Cloud Monitoring の指標が Managed Service for Prometheus で利用可能に
- クエリランゲージを使ってログをクエリできるように
Cloud Monitoring の指標が Managed Service for Prometheus で利用可能に
Others
- Open Source Insights のデータを BigQuery に
- 2022/05/13 に発表
- パッケージを解析
- 依存関係など
- deps.dev
- 依存関係をグラフ表示できる
Open Source Insights のデータを BigQuery に導入して、ソフトウェア サプライ チェーンの安全性を確保
- Assured Open Source Software
- 依存関係上で脆弱性を捕まえるのはマニュアルでやると煩雑だが、それを仕組み的に解決
Google Cloud の新サービス「Assured Open Source Software」のご紹介
https://cloud.google.com/blog/ja/products/identity-security/introducing-assured-open-source-software-service
質疑応答
Q. Cloud Run 第 2 世代と第 1 世代の位置付け (置き換え的な)
現時点では、プレビューステージなので検証にとどめていただきたい。
GAに向けて調整中で、コールドスタートのギャップ解消も取り組んでいる。
GA後は、第 2 世代中心にご利用いただければ。
Q. Cloud Functions / Cloud Run から Cloud SQL を使うときの注意点
前提条件として、Cloud SQL はリレーショナルデータベースのマネージドサービス。
暗黙的にプラットフォーム側でよろしくやってくれているのが、DB接続の認証（MySQLのパスワードなど）です。
公式ドキュメントの手順をなぞると気付かないかもしれませんが、DBのパスワード認証をアプリケーションで一切触らない。
ただし、ローカルのコンテナで開発する場合は、Cloud SQL Auth Proxy を明示的に使う必要があるので要注意。
Q. Zenn.dev から見た Cloud Run Jobs のユースケース
(例えば、マシンパワーが必要になる全文検索の形態素解析とか一括でやりたいときとか?)
マシンパワーが必要になる部分は実行環境の制約に照らし合わせていただく形になります。 一方で定期実行して、集計をしているものなど、候補としていいと思います。 例えば、タグとかトレンドにあるランキング的な定期的にアップデートしているものは良さそうです。（一時間に一回実行）
Q. もともと App Engine、今では Cloud Run を使っている。どう使い分けるのがよさそう
一言で言ってしまうと、 App Engine はソースコードをローカルで開発してデプロイ、 Cloud Run はコンテナ開発のワークフロー・ワークサイクルをベースにしている。ローカルでコンテナベースで開発している場合は Cloud Run がぴったり。
今後の機能拡張も Cloud Run が中心になるので、どんどん採用していただいても良さそう。
Q. Zenn.dev は App Engine から Cloud Run へ移行したが、使ってみてどうですか
一言で言うといい感じ！
チームと話して、Cloud Run に移行して良かったなって思うところのが、App Engine と比較して起動が速いってところ。
そのメリットとして、Zenn.dev の場合、記事がバズった場合サーバーに負荷がかかっちゃう、そんなときでも Cloud Run の場合はスケールしやすいというところもある。心理的なところでリリースのハードルを下げるところがある。起動が早いと安心感がある。
Q. Zenn.dev で苦労した点
移行するときはトラブルが起きがち、移行した当初は Zenn で記事がバズった時とか急にアクセスが増えた時に対応できるスペックのチューニングには苦労した。一番初めの頃は控えめのスペックにしていたが、対応できない時があった。コストの兼ね合いもあった。Rails つかっていると、最初のロードの時間なども考慮に入れる必要ありそう。
Q. Zenn.dev の開発体制
チーム全体として5名で運営しています。開発者としては4人。5人の中で新規開発、運用、コミュニティからの要望対応を全て行なっている。
運用は結構気にして、自動化はもちろん、セキュリティなども Cloud Armor で DDoS の対策をしたり、障害が発生した時のアラートの仕組みと、できるだけ人の手を介在させないようにしてます。
いいチームなのでめちゃくちゃ楽しいです！
Q. Zenn.dev の規模について（PVとかコストとか言える範囲で・・・）
・・・・・・・是非動画を参照してください！
まとめ
今回はゲストスピーカーをお招きしてセッション形式で行いましたが、 Zenn.dev のちょっと気になる話まで切り込んだりと色々楽しいトークができたので開催してよかったと思います。
動画は期間限定公開になりますが、期間中に是非参照してください。
9
