環境の一致について考えてみる / Environment Parity

Transcript

1. 環境の⼀致について考えてみる 春⼭ 誠 Makoto Haruyama May, 13, 2019 Container Build Meetup #2
2. DeNA E-Commerce & Incubation Unit, Service Incubation Div., Rerep Gr. SpringMT Spring_MT 春⼭ 誠 Makoto Haruyama
4. 注意 Railsの話がちょこちょこ出てきます • 他のFWでどうやっているかがいまいちわからず、⽐較もしない状態 で出てきます。。。
5. 社内におけるRailsを利⽤したサービスの開発/運⽤の実績 • ReRepのサービス構造と似ているサービスの実績もあり 管理画⾯の作りやすさ Webフレームワークに関しては慣れたものを採⽤して
 それ以外の部分でチャレンジする Ruby on Railsの採⽤
6. 閑話休題
7. 環境 複数環境がある場合がほとんど • 開発環境、QA環境、staging環境、本番環境。。。 • 本番環境しかないというのであれば、今回の話は。。。 複数環境ある場合、環境間の差異はなくしたい • 例: QA環境で検証済であれば、本番環境でも同じように検証した項⽬ の動作は保証される
8. 今⽬指している姿 Deep Environment Parity • コードの⼀致 • 実⾏パスも⼀致させる • 実⾏環境の⼀致 • ミドルウェアとかも同じ設定にする • データの⼀致 • 設定データ • マスターデータ
9. コードと実⾏環境とデータ コード 実⾏環境 • いわゆるインフラ側 • コードを動かす環境 • 永続化されているデータの管理 • いわゆるサーバー側 • ビジネスロジックの実装
 (永続化されているデータを⽤いて サービスの振る舞いを定義する) サービスを運⽤する上で必要な様々な設定や利⽤者のデータ データ
10. コードの⼀致
11. コードの⼀致 全ての環境で全く同じコードを使う 全ての環境で同じコードの実⾏パスを通る
12. コードの書き⽅
13. 全ての環境で同じ実⾏経路を通るようにする 1つの環境で動けば他の環境でも動くようにしたい • 実⾏経路が違うと本番環境だけで起こるような障害も。。 • 読み込む設定データの切り替えによって環境の差が⽣まれる NG OK
14. 設定ファイルの切り替え Entrykitのprehookを使って設定ファイルを切り替える
15. 切り替えるためのスクリプト
16. 時刻処理 同じ状況を再現できるようにする • 検証⽤に⽤意する時間調整機能 • ただし環境の差をなるべく⼩さくする
17. Docker
18. Docker 全ての環境で動作可能なDocker イメージにする 全ての環境で同じDocker イメージを使う
19. Dockerイメージに含めるもの サービスの振る舞いに必要なもの • コード • 開発⾔語やライブラリは全部同梱する • 設定データ • 全ての環境の設定データを⼊れておく
20. 設定ファイル or 環境変数 設定ファイル • サーバー側 環境変数 • インフラ側 ファイル保存⽤のGCSの認証情報 管理画⾯のレイアウトの⾊ MASTER_KEY MySQLのホストやパスワード サービスの振る舞いに 関係する設定をする サービスの振る舞いに 関係ない設定をする
21. 設定ファイルの管理 設定ファイルに秘匿情報を含めて管理 • RailsのEncrypted Credentialsを使って暗号化して管理 • 復号化するためのkeyは環境変数でインフラ側で管理している 環境を識別する環境変数を使って読み込む設定ファイルを 切り替える • RAILS_ENVは使わないよ
22. Dockerイメージの作成と管理
23. Dockerイメージの作成と管理 コードをpushする毎にDockerイメージを作る • Dockerイメージを作れないとリリースできないので毎回作りきる • ビルドは⼀回のみ、ビルドは⼀回のみ、ビルドは⼀回のみ 作成したDockerイメージは全て保存する • いつでも使える状態で保存しておく
24. Docker イメージのビルドはgitのコミットハッシュごとに⼀回だけ QA完了したので本番⽤のDocker イメージビルドします！ じゃなくてQA完了したDocker イメージはそのまま本番で も使う • 1 bitも変えないよ • stringsコマンドとかddコマンドを駆使して無理やり置換とかしても だめだよ
25. Dockerイメージの作成フロー  ! " 
            ςετ   
    
26. 本番環境 検証環境と本番環境でGCPのプロジェクトが別れている • Docker registryも分かれている この2つの環境を⾏き来できるのはDockerのイメージのみ
27. 本番環境へのイメージを移⾏ gcloudコマンドでGCPのプロジェクトを跨いで移⾏ • gcloud container images add-tag あとはdeployサーバーからsandboxと同じコマンドを打 つだけ • CDはまだできていない
28. 実⾏環境の⼀致
29. Kubernetes Dockerコンテナのオーケストレーションツール • サービスディスカバリとロード・バランシング 宣⾔的にかける設定とyamlで定義できる設定
30. kubernetesの設定について
31. 環境の差分をなくす 検証環境と本番環境でなるべく同じにしたいが • 環境の構成内容の質は変えたくないが、量は変えたい • 例: 検証環境ではPodの数を減らしたい(お⾦ないので、、) • 環境ごとに変えなければいけない設定だけを簡単に管理する
32. 設定の差分 Ingressのhost名の設定 Deploymentのreplicaの数 環境を分けるために作ったRRP_STAGEという環境変数 • RRP_STAGEでDockerコンテナ起動時の設定の切り替えを⾏う
33. 差分だけをうまく管理したい kustomize • 共通な設定を定義しつつ、overlayで各環境毎の設定を上書き可能 • kubernetesのyamlのまま管理でき、kubernetesの設定以上に覚え ることがない • baseを本番環境にして、その他の環境ではそれに対してパッチを当 てていく
34. パッチの例 recplicasの数に応じてHPAの設定 やDeploymentで要求する resourceの値を変更 Webサーバーのworker数はリ ソース状況をみてインフラ側で制 御できるよう環境変数で管理
35. データの⼀致
36. データのいろいろ 設定データ • コードを動かすために必要なデータ マスターデータ • サービスを運⽤する上で運営側が⽤意するデータ(画像含む) ユーザーデータ • ユーザーが作りだすデータ
37. コントロールできるデータ サービス運営側が決められるもの • 設定データ • マスターデータ これらを環境毎に⼀致できるようにする
38. 設定データ 前のスライドでも説明したとおり、Docker イメージの中 に全部いれておく
39. マスターデータ ⽂字列で表現できるデータはDBに保存して利⽤する バイナリ(主に画像)は即したストレージに保存(今回は GCS)
40. 運営が⽤意するマスターデータ ReRepではサービスのコンテンツはサービス運営側が⽤意 運⽤が⽤意するデータを環境に依存せず管理することで、 データも含めて環境の差異をコントロール • データの⾃動⽣成や反映はエンジニア以外で完結できる
41. ReRepでのマスターデータ 例 • ミッションという機能 • ミッションの説明⽂ • 達成条件 • ミッションの説明画像
42. マスターデータのポリシー Portable • 全ての環境に容易に適⽤できる Immutable • ⼀回作ったマスターデータに⼿を⼊れない
43. マスターデータの管理 SpreadSheet 画像 画像 GitHub Version A Version A /Version A/画像
44. ⽂字列のデータはDBに⼊れる 全て運営側で決めたkeyで紐付ける • keyは運営側でかぶらないように決める • 例 ミッション • ユーザのミッションクリアの対象ミッションはkeyで紐付ける データの登録は洗い替え • 全部Delete -> 全部Insert
45. 画像 毎回新しくGCSのディレクトリを作ってそこに保存する • 現在使うべき画像のパスが毎回変わる • 現在のアセットパスを返すAPIを⽤意し、アプリ⽴ち上げ時にAPI を叩いてもらう • 今の所パージとかはしていないが、できるように整備してある • CDNのキャッシュクリアとかはなし
46. 結果
47. 結果 リリース後の障害 • どうしてもいれなければならなかった環境での出し分けで1件のバグ (ユーザーを⼊れる前の検証で発覚) 運⽤時のトラブル • 画像の取り違え 1件 当社⽐ですが、かなり安定しているプロダクトとして存在 しています