Tweet
Tweet

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件 当社⽐ですが、かなり安定しているプロダクトとして存在 しています