Helpfeel Tech Conf 2024 - hiroshi 登壇資料 - Gyazo 開発 Platform Engineering
自己紹介
主な情報入手ルートは毎朝の HackerNews top 30
Gyazo のプロダクトエンジニア
器用貧乏なのでサーバーサイドとかインフラを担当
サーバー管理とか mutable な環境嫌いなのでコンテナなど immutable なのが好き
> Night gathers, and now my watch begins.
Platform Engineering とは?
よくわかってません
SRE も
僕の理解では...
広い意味でプロダクトのユーザーに価値が直接届かないような作業
自分を含めたエンジニアが快適に作業できるようにする工夫全般
DevOps とかも含む
ふつうにみんなやってること
やりすぎると AWS が誕生しちゃうらしい
日本語で「基盤」と言ってしまうとちょっと違う感じがする
前提知識として
Gyazo の歴史
Gyazo の開発環境
Gyazo の production 環境
Gyazo の CI/CD
Gyazo 開発/運用の歴史
2007 増井さんが個人サーバーでサービス開始
perl か ruby CGI みたいな実装
2009ごろ? 旧 nota 社の事業として引き取る
PHP になった?
Storage は S3
2014 Rails + Go
一部 heroku もあったり
deploy は capistrano とか懐かしい
2015 GCE (Google Compute Engine)
Srorage も GCS (Google Cloud Storage)
2020 GKEにほぼ移行
GKE (Google Kubernetes Engine)
Kubenetes は docker image などのコンテナ管理ツールの defact standard みたいなやつです
もうちょいで 20年
Gyazo の開発環境
2016ごろから主に mac か windows で Docker Desktop
最初は MongoDB だけとか
2020 GKEで deploy している同じ Dockerfile で開発できるように
docker compose で必要なものは揃うはず
ruby, node.js とか native install は必須ではない
Gyazo の production 環境
今はほぼ GKE に集約できてます
rails の https://gyazo.com/
golang の https://i.gyazo.com/
(upload とか画像/動画 バイナリ扱うやつは golang)
cronjob や background job (delayed_job)とかも
staging も別の GKE cluster がある
Gyazo の CI/CD
git flow みたいなやつ
一般的には development ブランチから feature X ブランチ派生で development から main ブランチにマージでリリースだと思います
Gyazo では main から featrure ブランチで main から production にマージするとリリースされる
こういう github actions workflows で
main にマージされると release PR と呼ばれるものが作られて
production ブランチにマージされると tag 付けて github release を作成
deploy は google cloud build
ブランチによって deploy 先を変更...
Gyazo 的解釈の Platform Engineering
現場の雰囲気を感じたり、なるほど、みたいに思ってもらえると幸いです
ぶっちゃけそれがベストかどうかわからんのでもっといい方法があったら後で教えてください
具体的な取り組みをいくつか紹介します
① 開発環境の MongoDB バージョンアップ支援
② production/staging の rails console (REPL)
③ one-off batch 処理は branch で background job 作って実行
④ action-cov (CI)
開発環境の MongoDB バージョンアップ支援
「開発環境でもMongoDBのバージョン更新するので各自以下のコマンドで featureCompatibilityVersion を更新してください」とか slack で伝えても、後日「docker compose の MongoDB 起動しなくなった」みたいなことになる
ローカルの rails 起動時に自動で設定してしまえば OK
config/environments/development.rb # Confirm MongoDB Featurecompatibilityversion
def mongodb_feature_compatibility_version
Gem::Version.new(Mongoid.default_client.use('admin').command({ getParameter: 1, featureCompatibilityVersion: 1 }).first.dig('featureCompatibilityVersion', 'version'))
end
config.after_initialize do
version = mongodb_feature_compatibility_version
if version < Gem::Version.new('5.0')
Rails.logger.info "MongoDB featureCompatibilityVersion: #{version} -> 5.0"
Mongoid.default_client.use('admin').command({ setFeatureCompatibilityVersion: '5.0' })
end
Rails.logger.info "MongoDB featureCompatibilityVersion: #{mongodb_feature_compatibility_version}"
endと思ってたら nonaさんが 6.0 更新時にやってくれた!! エライ
production/staging の rails console (REPL)
開発環境だったら
shdocker compose run --rm app bundle exec rails consoleGCE みたいなサーバーでも ssh すればよい
heroku にも
heroku run があるGKE の場合、同じ image の pod(コンテナ)を作れば(ほぼ同じ環境になる)
sh kubectl \
run gyazorails-console-$USER \
--image=XXXX/gyazo/gyazorails:master \
--image-pull-policy=Always \
--env=RAILS_ENV=staging \
--env=GYAZO_BRANCH=master \
-ti --rm \
--overrides='{ "spec": { "serviceAccount": "gyazorails" } }' \
bundle exec rails cServiceAccount では足りない secret へのアクセスなど必要な場合は
kubectl exec で実際に request を捌いているコンテナに入ったりもしますこのへんは kuberntes 使ってればみんなやってることだとは思いますが...
run 的な機能で REPL できないみたいone-off batch 処理は branch で background job 作って実行
時間のかかるone-off (使い捨て) batch 処理を実行したいときがある
console だとコケたりしたりときのやり直しとか気を抜けない
そのままだと数日かかっちゃうやつは並列化したい
background job のしくみを使うと便利
GKE (kubernetes) の job じゃないです
Gyazo ではブランチごとに background job (delayed_job) の queue を分離
feature branch でも専用の delayed_job の deployment (pods) が存在
そのブランチで
rails console 起動して TheJob.perfom_later(...) ログは GKE log で残るし
並列実行したいときは
kubectl scale --replicas=10 ... とかで増やして 10.times{|n| TheJob.perform_later(n) } とかするpull request レビュー受けられるし、 one-off だったらマージしない
action-cov (CI)
まじめに test corverage とかやるのはアホらしい
Rails の新しい
controller#action 追加したのにテスト書かない輩にいちいちレビューで指摘するのが面倒rspec 実行するときに
#{controller}##{action} みたいなのを保存最後に routes と比較して足りないやつを指摘
同じような感じで localization の key の過不足指摘するやつも i18n-tasks を使って実装
他には?....
2022年の /nota-techconf/Gyazo と GKE でも
feature branch の deploy (preview app みたいなやつ) とかの話や
deploy したら slack 通知で rolllback のやり方通知したりとか...
上記 on-off batch 処理のやつもこれの応用
staging の TLS cert を certbot で Google HTTP Load balancer に設定する k8s cronjob の話とかもあったりするのでまたいつか... (wildcard なので google managed は使えないと思っている)
まとめ
自社サービスプロダクトのエンジニアやってますが、自分が欲しいものしかわからない
Gyazo, Cosense は仕事でも private でも使う
こういう開発支援はターゲットが自分とその仲間なのでめっちゃモチベーションが上がる
そういう積み重ねでプロダクトのユーザーにも価値が提供できるといいなと思います