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

by Spring_MT

Embed

Start on current slide

Slide 1

Slide 1 text

環境の⼀致について考えてみる春⼭誠 Makoto Haruyama May, 13, 2019 Container Build Meetup #2

Slide 2

Slide 2 text

DeNA E-Commerce & Incubation Unit, Service Incubation Div., Rerep Gr. SpringMT Spring_MT 春⼭誠 Makoto Haruyama

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

注意 Railsの話がちょこちょこ出てきます • 他のFWでどうやっているかがいまいちわからず、⽐較もしない状態で出てきます。。。

Slide 5

Slide 5 text

社内におけるRailsを利⽤したサービスの開発/運⽤の実績 • ReRepのサービス構造と似ているサービスの実績もあり管理画⾯の作りやすさ Webフレームワークに関しては慣れたものを採⽤して  それ以外の部分でチャレンジする Ruby on Railsの採⽤

Slide 6

Slide 6 text

閑話休題

Slide 7

Slide 7 text

環境複数環境がある場合がほとんど • 開発環境、QA環境、staging環境、本番環境。。。 • 本番環境しかないというのであれば、今回の話は。。。複数環境ある場合、環境間の差異はなくしたい • 例: QA環境で検証済であれば、本番環境でも同じように検証した項⽬の動作は保証される

Slide 8

Slide 8 text

今⽬指している姿 Deep Environment Parity • コードの⼀致 • 実⾏パスも⼀致させる • 実⾏環境の⼀致 • ミドルウェアとかも同じ設定にする • データの⼀致 • 設定データ • マスターデータ

Slide 9

Slide 9 text

コードと実⾏環境とデータコード実⾏環境 • いわゆるインフラ側 • コードを動かす環境 • 永続化されているデータの管理 • いわゆるサーバー側 • ビジネスロジックの実装  (永続化されているデータを⽤いてサービスの振る舞いを定義する) サービスを運⽤する上で必要な様々な設定や利⽤者のデータデータ

Slide 10

Slide 10 text

コードの⼀致

Slide 11

Slide 11 text

コードの⼀致全ての環境で全く同じコードを使う全ての環境で同じコードの実⾏パスを通る

Slide 12

Slide 12 text

コードの書き⽅

Slide 13

Slide 13 text

全ての環境で同じ実⾏経路を通るようにする 1つの環境で動けば他の環境でも動くようにしたい • 実⾏経路が違うと本番環境だけで起こるような障害も。。 • 読み込む設定データの切り替えによって環境の差が⽣まれる NG OK

Slide 14

Slide 14 text

設定ファイルの切り替え Entrykitのprehookを使って設定ファイルを切り替える

Slide 15

Slide 15 text

切り替えるためのスクリプト

Slide 16

Slide 16 text

時刻処理同じ状況を再現できるようにする • 検証⽤に⽤意する時間調整機能 • ただし環境の差をなるべく⼩さくする

Slide 17

Slide 17 text

Docker

Slide 18

Slide 18 text

Docker 全ての環境で動作可能なDocker イメージにする全ての環境で同じDocker イメージを使う

Slide 19

Slide 19 text

Dockerイメージに含めるものサービスの振る舞いに必要なもの • コード • 開発⾔語やライブラリは全部同梱する • 設定データ • 全ての環境の設定データを⼊れておく

Slide 20

Slide 20 text

設定ファイル or 環境変数設定ファイル • サーバー側環境変数 • インフラ側ファイル保存⽤のGCSの認証情報管理画⾯のレイアウトの⾊ MASTER_KEY MySQLのホストやパスワードサービスの振る舞いに関係する設定をするサービスの振る舞いに関係ない設定をする

Slide 21

Slide 21 text

設定ファイルの管理設定ファイルに秘匿情報を含めて管理 • RailsのEncrypted Credentialsを使って暗号化して管理 • 復号化するためのkeyは環境変数でインフラ側で管理している環境を識別する環境変数を使って読み込む設定ファイルを切り替える • RAILS_ENVは使わないよ

Slide 22

Slide 22 text

Dockerイメージの作成と管理

Slide 23

Slide 23 text

Dockerイメージの作成と管理コードをpushする毎にDockerイメージを作る • Dockerイメージを作れないとリリースできないので毎回作りきる • ビルドは⼀回のみ、ビルドは⼀回のみ、ビルドは⼀回のみ作成したDockerイメージは全て保存する • いつでも使える状態で保存しておく

Slide 24

Slide 24 text

Docker イメージのビルドはgitのコミットハッシュごとに⼀回だけ QA完了したので本番⽤のDocker イメージビルドします！じゃなくてQA完了したDocker イメージはそのまま本番でも使う • 1 bitも変えないよ • stringsコマンドとかddコマンドを駆使して無理やり置換とかしてもだめだよ

Slide 25

Slide 25 text

Dockerイメージの作成フロー ! " ςετ

Slide 26

Slide 26 text

本番環境検証環境と本番環境でGCPのプロジェクトが別れている • Docker registryも分かれているこの2つの環境を⾏き来できるのはDockerのイメージのみ

Slide 27

Slide 27 text

本番環境へのイメージを移⾏ gcloudコマンドでGCPのプロジェクトを跨いで移⾏ • gcloud container images add-tag あとはdeployサーバーからsandboxと同じコマンドを打つだけ • CDはまだできていない

Slide 28

Slide 28 text

実⾏環境の⼀致

Slide 29

Slide 29 text

Kubernetes Dockerコンテナのオーケストレーションツール • サービスディスカバリとロード・バランシング宣⾔的にかける設定とyamlで定義できる設定

Slide 30

Slide 30 text

kubernetesの設定について

Slide 31

Slide 31 text

環境の差分をなくす検証環境と本番環境でなるべく同じにしたいが • 環境の構成内容の質は変えたくないが、量は変えたい • 例: 検証環境ではPodの数を減らしたい(お⾦ないので、、) • 環境ごとに変えなければいけない設定だけを簡単に管理する

Slide 32

Slide 32 text

設定の差分 Ingressのhost名の設定 Deploymentのreplicaの数環境を分けるために作ったRRP_STAGEという環境変数 • RRP_STAGEでDockerコンテナ起動時の設定の切り替えを⾏う

Slide 33

Slide 33 text

差分だけをうまく管理したい kustomize • 共通な設定を定義しつつ、overlayで各環境毎の設定を上書き可能 • kubernetesのyamlのまま管理でき、kubernetesの設定以上に覚えることがない • baseを本番環境にして、その他の環境ではそれに対してパッチを当てていく

Slide 34

Slide 34 text

パッチの例 recplicasの数に応じてHPAの設定やDeploymentで要求する resourceの値を変更 Webサーバーのworker数はリソース状況をみてインフラ側で制御できるよう環境変数で管理

Slide 35

Slide 35 text

データの⼀致

Slide 36

Slide 36 text

データのいろいろ設定データ • コードを動かすために必要なデータマスターデータ • サービスを運⽤する上で運営側が⽤意するデータ(画像含む) ユーザーデータ • ユーザーが作りだすデータ

Slide 37

Slide 37 text

コントロールできるデータサービス運営側が決められるもの • 設定データ • マスターデータこれらを環境毎に⼀致できるようにする

Slide 38

Slide 38 text

設定データ前のスライドでも説明したとおり、Docker イメージの中に全部いれておく

Slide 39

Slide 39 text

マスターデータ⽂字列で表現できるデータはDBに保存して利⽤するバイナリ(主に画像)は即したストレージに保存(今回は GCS)

Slide 40

Slide 40 text

運営が⽤意するマスターデータ ReRepではサービスのコンテンツはサービス運営側が⽤意運⽤が⽤意するデータを環境に依存せず管理することで、データも含めて環境の差異をコントロール • データの⾃動⽣成や反映はエンジニア以外で完結できる

Slide 41

Slide 41 text

ReRepでのマスターデータ例 • ミッションという機能 • ミッションの説明⽂ • 達成条件 • ミッションの説明画像

Slide 42

Slide 42 text

マスターデータのポリシー Portable • 全ての環境に容易に適⽤できる Immutable • ⼀回作ったマスターデータに⼿を⼊れない

Slide 43

Slide 43 text

マスターデータの管理 SpreadSheet 画像画像 GitHub Version A Version A /Version A/画像

Slide 44

Slide 44 text

⽂字列のデータはDBに⼊れる全て運営側で決めたkeyで紐付ける • keyは運営側でかぶらないように決める • 例ミッション • ユーザのミッションクリアの対象ミッションはkeyで紐付けるデータの登録は洗い替え • 全部Delete -> 全部Insert

Slide 45

Slide 45 text

画像毎回新しくGCSのディレクトリを作ってそこに保存する • 現在使うべき画像のパスが毎回変わる • 現在のアセットパスを返すAPIを⽤意し、アプリ⽴ち上げ時にAPI を叩いてもらう • 今の所パージとかはしていないが、できるように整備してある • CDNのキャッシュクリアとかはなし

Slide 46

Slide 46 text

結果

Slide 47

Slide 47 text

結果リリース後の障害 • どうしてもいれなければならなかった環境での出し分けで1件のバグ (ユーザーを⼊れる前の検証で発覚) 運⽤時のトラブル • 画像の取り違え 1件当社⽐ですが、かなり安定しているプロダクトとして存在しています