Rails on GKEで運用するWebアプリケーションの紹介

Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved.Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved.
Jun 9, 2018
Spring_MT
DeNA Co., Ltd.
Rails on GKEで運用するWebアプリケーションの紹介

Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved.
自己紹介
• 自己紹介
2
 2008年 DeNA入社
 2010年エンジニアになる
 2011年 DeNA退社 -> 福岡へ
 2013年 DeNAに出戻り
 2016年ゲーム事業本部
 2017年コマース&インキュベーション事業本部
GitHub https://github.com/SpringMT
Twitter https://twitter.com/Spring_MT
@Spring_MT

開発チーム
スモールスタート
• フロント1名
• サーバー・インフラ1名
3

機能開発に集中するために
4
• 機能開発以外のやることを減らしたい
• 運用業務をシンプルにしたい

5
今回お話する内容
https://builderscon.io/tokyo/2018/session/b87465f5-4a05-4a6b-85c6-a50ab205dc27

今回お話する内容
6
モノリシックな作り
APIファースト
本番環境と同じ開発環境
サービスのコンテンツデータの運用

目次
環境のギャップをなくす
• Dockerを使ったイメージベースの成果物
• 設定ファイルの管理
• 反映方法
構成のギャップをなくす
• Kubernetes(GKE)
• その他
まとめ
7

コードベースを同じに

Dockerを使ったイメージベースの成果物管理
• イメージを作成したら変えない
• ビルドは一回
• ddとか使ってバイナリをいじるようなことはしない
• 起動時にコードを追加するなどもしない
• 検証環境・本番環境でも動くようなイメージの構成にする
• なにも手を加えずに検証環境から本番環境にイメージを
移行させる
9

検証環境と本番環境でGCPのプロジェクトをわける
• 検証環境と本番環境を完全に分離する
• 検証環境はQA専任チームなど別チームも閲覧・操作する
• 本番環境は開発者のみ
• この2つを行き来できるのはDockerのイメージのみ
アプリケーションのデータ運用(マスターデータ・アセット)は
最初から考えておく
10

Dockerのイメージの構成
• 3種類のイメージにわけて作成
• 設定ファイルなどは全てのイメージに含まれる
11
├ api
├ DB_Schema
├ 管理ツール
├ config(subtree)
├ shared
API DB Schema 管理ツール
├ api
├ config(subtree)
├ shared
├ DB Schema
├ config(subtree)
├ shared
├ 管理ツール
├ config(subtree)
├ shared

Dockerのイメージの構成
• stretchベース (NOT alpine)
glibcがなくて、stackdriver(の中のgrpc)のgemがビルドできない
12

Docker registry
Dockerの社内registryは自前で用意はしない
Googleのパワーを借りる
• Google Container Builder
• Google Container Registry
13

社内リソースとの連携
Container Builderを使うための調整
• GitHub:Enterprise、CircleCI Enterprise、社内rubygemsがある
• Container BuilderはGH:EにはアクセスできないのでGoogle Source
Repositoryを経由する
• 社内rubygemsは利用しない(社内gemは使わない)
• 使う場合はレポジトリに直接subtree等で取り込むことを想定
14

15
Dockerのイメージ作成フロー
テストが通ったブランチは全部イメージを作る
Developers
Cloud Source
Repositories
Container
Registry
Container
Builder
HookPush
テスト実行
Push
DeNA

Dockerのイメージ作成
CircleCIからSource Repositoryへpush
16
deploy:
machine:
enabled: true
steps:
- checkout
- run:
command: echo "${LIVE_SB_NETRC}" > ~/.netrc
- run:
command: git remote add google https://source.developers.google.com/p/sample/r/server
- run:
command: git push google "${CIRCLE_BRANCH}"

Dockerのイメージ作成
17
Container BuilderではDockerfile指定だけ
• 凝ったことは特にしていない
• 1プロジェクトあたり10件の同時ビルドが可能
• 本プロジェクトでは3つは同時にビルドしたい

本番環境へのイメージの移行
検証環境でテストしたイメージをそのまま本番環境に移行
• gcloudコマンドでGCPのプロジェクトを超えて持っていける
• gcloud container images add-tag
18

Rails
RAILS_ENV
• 検証環境・本番環境はproductionで統一
• 環境を規定するために別の環境変数を用意
• Docker起動時に設定を読み込む
19

Rails
20
ENV RAILS_ENV production
# Use EntryKit
ENTRYPOINT [
"prehook", "ruby -v", "--",
"prehook", "bundle exec ruby shared/scripts/setup.rb", "--",
"switch",
"shell=/bin/sh",
"rails_c=bundle exec rails c",
"rails_db=bundle exec rails db",
"rails_s=bundle exec rails s -b 0.0.0.0", "--",
"bundle", "exec", "unicorn_rails", "-c", "config/unicorn/production.rb" ]

Rails
サーバーの設定
config用のレポジトリを用意し、subtreeで取り込み
Logは標準出力に
stackdriver loggingで回収 -> exportして各処理へ
パフォーマンス測定
本番環境はstackdriver trace
検証環境はstackdriver traceに加えてstackprofでも確認する
21

22
Rails

構成を同じに

サーバーの構成を同じに
構成を同じに
kubernetes(GKE)を使った構築
Dockerのイメージの動作環境という視点でまずは選定
その上で
• 構成をそろえやすい
• 少人数でも管理・運用しやすい
24

kubernetesの管理
構成を同じに
設定はyamlで管理
• 規模感的にまだHemlとかを導入するほどでもない
• kustomizeは検討中
• Service + HPA + Deploymentで一つのyamlにまとめている
• 環境ごとの差分はなるべく少なく
• replicasの数くらいが差分になっている
25

kubernetesの構成
構成を同じに
ConfigMapとSecret
• 環境変数(ConfigMap、Secret)とアプリ内でもつ設定の分離
• 秘密情報は全てSecretを使って環境変数経由で受け渡す
• アプリケーションの設定情報はコードに含め環境変数で受け渡すことは基
本的にしない
• unicornのworker数などこまめに調整する数値のみ環境変数で管理
26

kubernetesの構成
構成を同じに
Service、HPA、Deployment
• API、管理ツール等ではreplicas以外の差はない
• HPAの設定、deploymentのProbeの設定を忘れずに
• graceful shutdownとスケーリングをちゃんと設定しておく
• 負荷試験時にイメージの更新を挟むことで確認
27

28
全体の構成
構成を同じに
Monitoring
Logging
Cloud Load
Balancing Cloud
SQL
Trace
Error
Reporting
Frontend
API
管理ツール
Cloud
Storage
Container Engine

GKEの設定
構成を同じに
バージョン
• v1.10.5を利用
• stackdriver monitoring v2を利用したかった
29

GKEの設定
構成を同じに
本番環境ではマスター承認済みのネットワークを設定
• 社内のgatewayサーバーからのみアクセスできる
deployサーバー(GCE)を用意してそこからのみkubectlが打てる
• gatewayサーバーにはttyrecが仕込んであり
監査用にログが残してある
• 検証環境はローカルマシンからkubectlを打てる
30

GKEの設定
構成を同じに
限定公開クラスタは無効
• CloudSQLがプライベートGoogleアクセスに対応していない
• https://cloud.google.com/vpc/docs/private-google-access
• アプリケーションからは結局Cloud SQL Proxy経由でアクセス
31

GKEの設定
構成を同じに
ノードの自動スケーリングは開発環境はon 本番環境はoff
• スケールするときにサービス断の可能性あり
32

GKEの設定
構成を同じに
権限管理
• google group + IAMで管理が基本
• 本番環境と検証環境を分けており、本番環境には入れる人を絞っている
• kubernetesのRBACはまだ使ってない
33

GKEの設定
構成を同じに
Preemptible VM
• 検証環境は全てPreemptible
• コストダウンともに、環境が常に新しくdisposableであることの確認が可
能
34

kubernetesを使ったメリット
構成を同じに
DNSの管理からの開放
• MyDNSと決別
プロセスがおちたら自動的に再起動
• daemontoolsと決別
35

kubernetesを使ったメリット
構成を同じに
Horizonatal Pod Autoscaler
• 自動でpodの数を調整してくれる
• 負荷試験ではテストしているが、リリース後からは発動してない
36

kubernetesのデメリット
構成を同じに
比較になるが、GAE/Goほどシンプルではないかも…
• 管理するものが多い印象
37

ハマったこと
構成を同じに
CronJob
• sidecarがあるとsidecarが終わらない問題
• v1.10.5未満だと失敗したjobが延々とリトライし続ける問題があった(解消済)
graceful shutdownできていない
• CloudSQL ProxyのpreStopの設定
38

ハマったこと
構成を同じに
DBスキーマの適用
• スキーマ管理はridgepoleを採用
• スキーマ適用用のpodを上げてそこのpodに入ってコマンドを打つ
39

改善したいポイント
構成を同じに
検証環境のクラスターをまとめる
• 検証環境毎にクラスターを作っているので、ここをまとめて環境を作りや
すくする
40

GCPで使っているサービス(GKE以外)
構成を同じに
• CloudSQL
• stackdriver
• dataflow
• BigQuery
• GCS
• CloudFunction
41

GCP以外に使っているサービス
構成を同じに
AWS
• SES
• メールだけはどうしようもなかった。。
Fastly
• CDNとimage optimizer
• image optimizerで画像の配信を柔軟に行っている
42

実績
まとめ
コードの差によるバグ
• １件
• デバッグ機能をoffにする条件分岐
構成の差によるバグ
• なし
運用は今の所一人でも大丈夫
43

まとめ
まとめ
• Dockerやkubernetesを使って簡単に一貫性のある環境を
構築することができた
• その結果、環境起因による不具合を抑えることができて
いる(と思う)
44

Rails on GKEで運用するWebアプリケーションの紹介

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Rails on GKEで運用するWebアプリケーションの紹介

Similar a Rails on GKEで運用するWebアプリケーションの紹介 (20)

Más de Makoto Haruyama

Más de Makoto Haruyama (11)

Rails on GKEで運用するWebアプリケーションの紹介