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

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

Aa777465acd82d13333678f3fc082c59?s=128

Spring_MT

May 13, 2019
Tweet

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

    しています