Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
環境の一致について考えてみる / Environment Parity
Search
Spring_MT
May 13, 2019
Technology
4
7k
環境の一致について考えてみる / Environment Parity
Spring_MT
May 13, 2019
Tweet
Share
More Decks by Spring_MT
See All by Spring_MT
Deep Environment Parity CDNT 2019
spring_mt
5
3.2k
1人でできる Docker Kubernetes(GKE)を 使った新規サービス立ち上げ / Docker and Kubernetes(GKE) for new services
spring_mt
19
7.6k
CI CD Test on ReRep
spring_mt
3
3.2k
Swagger (OpenAPI 2.0) を使ったAPI仕様Drivenな開発 / API-Spec-Driven development with Swagger
spring_mt
9
3.2k
Rails on GKEで運用する Webアプリケーションの紹介/Rails on GKE
spring_mt
0
420
新規事業立ち上げからマイクロサービスについて考えてみる
spring_mt
1
1.1k
hpbn_3
spring_mt
0
92
backbone.jsの使用例 その1
spring_mt
0
320
chef-soloの簡単な使い方
spring_mt
4
930
Other Decks in Technology
See All in Technology
[AWS JAPAN 生成AIハッカソン] Dialog の紹介
yoshimi0227
0
140
急成長中のWINTICKETにおける品質と開発スピードと向き合ったQA戦略と今後の展望 / winticket-autify
cyberagentdevelopers
PRO
1
160
ネット広告に未来はあるか?「3rd Party Cookie廃止とPrivacy Sandboxの効果検証の裏側」 / third-party-cookie-privacy
cyberagentdevelopers
PRO
1
130
話題のGraphRAG、その可能性と課題を理解する
hide212131
4
1.4k
【若手エンジニア応援LT会】AWS Security Hubの活用に苦労した話
kazushi_ohata
0
160
Emacs x Nostr
hakkadaikon
1
150
Amazon_CloudWatch_ログ異常検出_導入ガイド
tsujiba
4
1.5k
MAMを軸とした動画ハンドリングにおけるAI活用前提の整備と次世代ビジョン / abema-ai-mam
cyberagentdevelopers
PRO
1
110
一休.comレストランにおけるRustの活用
kymmt90
3
580
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
120
プロダクトエンジニアが活躍する環境を作りたくて 事業責任者になった話 ~プロダクトエンジニアの行き着く先~
gimupop
1
460
Featured
See All Featured
Happy Clients
brianwarren
97
6.7k
Designing for Performance
lara
604
68k
A better future with KSS
kneath
238
17k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
Designing Experiences People Love
moore
138
23k
Building Your Own Lightsaber
phodgson
102
6k
Producing Creativity
orderedlist
PRO
341
39k
Building an army of robots
kneath
302
42k
The World Runs on Bad Software
bkeepers
PRO
65
11k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
GraphQLの誤解/rethinking-graphql
sonatard
66
9.9k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Transcript
環境の⼀致について考えてみる 春⼭ 誠 Makoto Haruyama May, 13, 2019 Container Build
Meetup #2
DeNA E-Commerce & Incubation Unit, Service Incubation Div., Rerep Gr.
SpringMT Spring_MT 春⼭ 誠 Makoto Haruyama
None
注意 Railsの話がちょこちょこ出てきます • 他のFWでどうやっているかがいまいちわからず、⽐較もしない状態 で出てきます。。。
社内におけるRailsを利⽤したサービスの開発/運⽤の実績 • ReRepのサービス構造と似ているサービスの実績もあり 管理画⾯の作りやすさ Webフレームワークに関しては慣れたものを採⽤して それ以外の部分でチャレンジする Ruby on Railsの採⽤
閑話休題
環境 複数環境がある場合がほとんど • 開発環境、QA環境、staging環境、本番環境。。。 • 本番環境しかないというのであれば、今回の話は。。。 複数環境ある場合、環境間の差異はなくしたい • 例: QA環境で検証済であれば、本番環境でも同じように検証した項⽬
の動作は保証される
今⽬指している姿 Deep Environment Parity • コードの⼀致 • 実⾏パスも⼀致させる • 実⾏環境の⼀致
• ミドルウェアとかも同じ設定にする • データの⼀致 • 設定データ • マスターデータ
コードと実⾏環境とデータ コード 実⾏環境 • いわゆるインフラ側 • コードを動かす環境 • 永続化されているデータの管理 •
いわゆるサーバー側 • ビジネスロジックの実装 (永続化されているデータを⽤いて サービスの振る舞いを定義する) サービスを運⽤する上で必要な様々な設定や利⽤者のデータ データ
コードの⼀致
コードの⼀致 全ての環境で全く同じコードを使う 全ての環境で同じコードの実⾏パスを通る
コードの書き⽅
全ての環境で同じ実⾏経路を通るようにする 1つの環境で動けば他の環境でも動くようにしたい • 実⾏経路が違うと本番環境だけで起こるような障害も。。 • 読み込む設定データの切り替えによって環境の差が⽣まれる NG OK
設定ファイルの切り替え Entrykitのprehookを使って設定ファイルを切り替える
切り替えるためのスクリプト
時刻処理 同じ状況を再現できるようにする • 検証⽤に⽤意する時間調整機能 • ただし環境の差をなるべく⼩さくする
Docker
Docker 全ての環境で動作可能なDocker イメージにする 全ての環境で同じDocker イメージを使う
Dockerイメージに含めるもの サービスの振る舞いに必要なもの • コード • 開発⾔語やライブラリは全部同梱する • 設定データ • 全ての環境の設定データを⼊れておく
設定ファイル or 環境変数 設定ファイル • サーバー側 環境変数 • インフラ側 ファイル保存⽤のGCSの認証情報
管理画⾯のレイアウトの⾊ MASTER_KEY MySQLのホストやパスワード サービスの振る舞いに 関係する設定をする サービスの振る舞いに 関係ない設定をする
設定ファイルの管理 設定ファイルに秘匿情報を含めて管理 • RailsのEncrypted Credentialsを使って暗号化して管理 • 復号化するためのkeyは環境変数でインフラ側で管理している 環境を識別する環境変数を使って読み込む設定ファイルを 切り替える •
RAILS_ENVは使わないよ
Dockerイメージの作成と管理
Dockerイメージの作成と管理 コードをpushする毎にDockerイメージを作る • Dockerイメージを作れないとリリースできないので毎回作りきる • ビルドは⼀回のみ、ビルドは⼀回のみ、ビルドは⼀回のみ 作成したDockerイメージは全て保存する • いつでも使える状態で保存しておく
Docker イメージのビルドはgitのコミットハッシュごとに⼀回だけ QA完了したので本番⽤のDocker イメージビルドします! じゃなくてQA完了したDocker イメージはそのまま本番で も使う • 1 bitも変えないよ
• stringsコマンドとかddコマンドを駆使して無理やり置換とかしても だめだよ
Dockerイメージの作成フロー ! "
ςετ
本番環境 検証環境と本番環境でGCPのプロジェクトが別れている • Docker registryも分かれている この2つの環境を⾏き来できるのはDockerのイメージのみ
本番環境へのイメージを移⾏ gcloudコマンドでGCPのプロジェクトを跨いで移⾏ • gcloud container images add-tag あとはdeployサーバーからsandboxと同じコマンドを打 つだけ •
CDはまだできていない
実⾏環境の⼀致
Kubernetes Dockerコンテナのオーケストレーションツール • サービスディスカバリとロード・バランシング 宣⾔的にかける設定とyamlで定義できる設定
kubernetesの設定について
環境の差分をなくす 検証環境と本番環境でなるべく同じにしたいが • 環境の構成内容の質は変えたくないが、量は変えたい • 例: 検証環境ではPodの数を減らしたい(お⾦ないので、、) • 環境ごとに変えなければいけない設定だけを簡単に管理する
設定の差分 Ingressのhost名の設定 Deploymentのreplicaの数 環境を分けるために作ったRRP_STAGEという環境変数 • RRP_STAGEでDockerコンテナ起動時の設定の切り替えを⾏う
差分だけをうまく管理したい kustomize • 共通な設定を定義しつつ、overlayで各環境毎の設定を上書き可能 • kubernetesのyamlのまま管理でき、kubernetesの設定以上に覚え ることがない • baseを本番環境にして、その他の環境ではそれに対してパッチを当 てていく
パッチの例 recplicasの数に応じてHPAの設定 やDeploymentで要求する resourceの値を変更 Webサーバーのworker数はリ ソース状況をみてインフラ側で制 御できるよう環境変数で管理
データの⼀致
データのいろいろ 設定データ • コードを動かすために必要なデータ マスターデータ • サービスを運⽤する上で運営側が⽤意するデータ(画像含む) ユーザーデータ • ユーザーが作りだすデータ
コントロールできるデータ サービス運営側が決められるもの • 設定データ • マスターデータ これらを環境毎に⼀致できるようにする
設定データ 前のスライドでも説明したとおり、Docker イメージの中 に全部いれておく
マスターデータ ⽂字列で表現できるデータはDBに保存して利⽤する バイナリ(主に画像)は即したストレージに保存(今回は GCS)
運営が⽤意するマスターデータ ReRepではサービスのコンテンツはサービス運営側が⽤意 運⽤が⽤意するデータを環境に依存せず管理することで、 データも含めて環境の差異をコントロール • データの⾃動⽣成や反映はエンジニア以外で完結できる
ReRepでのマスターデータ 例 • ミッションという機能 • ミッションの説明⽂ • 達成条件 • ミッションの説明画像
マスターデータのポリシー Portable • 全ての環境に容易に適⽤できる Immutable • ⼀回作ったマスターデータに⼿を⼊れない
マスターデータの管理 SpreadSheet 画像 画像 GitHub Version A Version A /Version
A/画像
⽂字列のデータはDBに⼊れる 全て運営側で決めたkeyで紐付ける • keyは運営側でかぶらないように決める • 例 ミッション • ユーザのミッションクリアの対象ミッションはkeyで紐付ける データの登録は洗い替え
• 全部Delete -> 全部Insert
画像 毎回新しくGCSのディレクトリを作ってそこに保存する • 現在使うべき画像のパスが毎回変わる • 現在のアセットパスを返すAPIを⽤意し、アプリ⽴ち上げ時にAPI を叩いてもらう • 今の所パージとかはしていないが、できるように整備してある •
CDNのキャッシュクリアとかはなし
結果
結果 リリース後の障害 • どうしてもいれなければならなかった環境での出し分けで1件のバグ (ユーザーを⼊れる前の検証で発覚) 運⽤時のトラブル • 画像の取り違え 1件 当社⽐ですが、かなり安定しているプロダクトとして存在
しています