Terraformを使ったステージング環境の再構築 / Rebuilding staging environment with terraform

■イベント
Sansan Builders Box 2019
https://jp.corp-sansan.com/sbb2019/

■登壇概要
タイトル：Terraformを使ったステージング環境の再構築

登壇者：
DSOC Infrastructure Group 藤田斉

▼Sansan Builders Box
https://buildersbox.corp-sansan.com/

Transcript

1. Terraformを使った ステージング環境の再構築
2. #33tech
3. 藤⽥ ⻫（Hitoshi Fujita） DSOC Infrastructure Group - お仕事 DSOCの名刺データ化システム、名寄システムのインフラ運⽤、改善 - 趣味 バスケットボール, TVゲーム - Twitter https://twitter.com/noobs_waneal - GitHub https://github.com/waneal
4. Sansan Builders Box ゴール - Terraformを使ったAWS環境構築で直⾯した課題を知ってもらう - AWSコスト、運⽤コストを最適化する⽅法を知ってもらう
5. Sansan Builders Box Agenda - 名寄システムについて - ステージング環境再構築 - 構築で直⾯した課題 - 今後やりたいこと
6. 名寄システムについて
7. Sansan Builders Box 名寄とは？ 名 寄 Sansan株式会社 藤⽥⻫ 会社と⼈物を識別する
8. Sansan Builders Box 会社の名寄とは？ ・会社：三三株式会社 ・部署：営業部 ・ドメイン：sansan.com ・会社：Sansan株式会社 ・部署：営業部 ・ドメイン：sansan.com ・会社：Sansan ・部署：営業部 ・ドメイン：sansan.com ・会社：Sansan株式会社 ・部署：スリー部 ・ドメイン：threethree.com 社名変更・合併 通称・略称 同名他社 Sansan株式会社
9. Sansan Builders Box 会社の名寄とSansan/Eightの関係 DSOC (Data Strategy & Operation Center) Sansan、Eight を⽀える存在 名寄システム データ化された 名刺の会社情報 名寄された 会社
10. Sansan Builders Box AWSアカウント構成 - 1つのAWSアカウントに複数システムが共存 - 歴史的経緯あり - 各環境の利⽤⽤途 - 本番環境 - ステージング環境 - 結合テスト - 本番と同じ構成 - インスタンスタイプ、台数は異なる - 開発環境 - 各種AWSサービスの検証
11. Sansan Builders Box インフラチームが抱える課題 - コストが明確に分離できない - タグをもとにシステム毎に算出しているが完全とは⾔えない - ネットワークコストなど - 構成・権限の複雑化 - IAMロール、Security Group, サブネットが複雑化
12. ある⽇、開発チームから相談が...
13. Sansan Builders Box リリース前のリハーサルの質を上げたい - ステージング環境はテストデータを利⽤ - テストデータでの結合検証のみ - 会社の名寄の結果までは確認できていない - リハーサルの質を上げたい - 本番相応の会社データを利⽤してこれを実現 - 会社データのため個⼈情報は含まれていない Sansan Builders Box
    
        - 
    "% 
    98 - 
     &*'.  - - 7$ & !3   - 
     +/ - 642 -
    98,( - -
     )105 #  
14. 本番環境・ステージング環境の 課題を解決すべくインフラ再構築 まずはステージング環境を再構築
15. Sansan Builders Box 名寄せシステムのインフラを再構築 - アカウントを分離 - アカウント毎でコスト算出 - 構成・権限をシンプルに - 開発効率向上 - 各環境の役割変更 - ステージング環境 - リリース前リハーサル - 結合テスト - 開発環境 - AWSサービス検証
16. Sansan Builders Box 名寄せシステムのインフラを再構築 今回の発表範囲 - アカウントを分離 - アカウント毎でコスト算出 - 構成・権限をシンプルに - 開発効率向上 - 各環境の役割変更 - ステージング環境 - リリース前リハーサル - 結合テスト - 開発環境 - AWSサービス検証
17. ステージング環境再構築
18. Sansan Builders Box AWS環境をコード化 - ⽬的 - 本番環境構築の作業コストを削減 - 環境間の設定差異をなくす - Terraformを採⽤ - Hashicorp製オープンソースのインフラ構築ツール - インフラの状態を保持、冪等性がある - 社内での利⽤実績多数
19. Sansan Builders Box AWSコストの最適化 - AWS Instance Scheduler - EC2, RDSの起動・停⽌をスケジューリング - AWS SolutionsとしてAmazonが提供 - CloudFormationで構築 - Redshift, Glueは必要なときだけ構築 - Terraformで利⽤したいときだけ作成 - dc2.large/RI/1年間の場合→1,645$ - 起動時間が18⽇/⽉ならオンデマンドのほうがお得 - コンテナ化 - それぞれEC2で起動していた管理系サーバを1台に集約
20. Sansan Builders Box 運⽤コストの最適化 - Terraformのコードはアプリ・インフラ両⽅が書く - インフラチームの運⽤コスト削減 - 全体の開発スピード向上 - 現在はインフラチームの作業がボトルネックに - ステージング環境の起動はSlackから - Slackコマンド → 共有ボット⽤EC2 → EC2, RDS起動
21. 構築で直⾯した課題
22. Sansan Builders Box どうやって別アカウントのRDSを持ってくるか - RDS（Aurora）から週次でクローン作成 - Auroraは2019/7/2よりアカウント間のクローンがサポート - CloudWatch Events + CodeBuild - クローンのほうがスナップショットからリストアするより安い - 本番のディスクを丸ごとステー ジングにコピー - ストレージコストが2倍 リストア - コピーオンライト。本番との差 分だけをステージングのディス クで持つ - 新規の書き込み分だけ費⽤がか かる クローン
23. Sansan Builders Box どこまでコード化するか - 全部Terraformで書きたい欲を抑える - 無理やりコード化するとメンテナンス性が低下する場合も - コード化しないと決めたもの - アプリケーション側だけで完結する部分 - Parameter Store、Lambdaのコード - CloudFormation - Instance Schedulerで利⽤ - コード化できなかった部分はドキュメントとして残す
24. Sansan Builders Box ディレクトリ構成をどうするか - システム毎に適したものを採⽤すべき - リソースをimmutable, mutableで分離 - メリット - tfstateが別れているのでplan, applyが早い - オンデマンドなリソース構築が楽 - デメリット - 依存関係を整理する必要がある - 環境毎の設定差異はtfvarsで定義 - prod.tfvars, stg,tfvars, dev.tfvars - workspace毎に作成 - 環境ごとでリソース要素が変わらないのでこの⽅法を選定
25. Sansan Builders Box ディレクトリ構成をどうするか
26. Sansan Builders Box Secretsをどうやって管理するか - データベースのパスワードやAPIキーなどをGitHubにアップしたくない - データソース: aws_ssm_parameterを利⽤ ただし、tfstateファイルに平⽂で書き込まれるので注意 tfstateファイルへのアクセス権限に気をつける
27. 移⾏した後の開発チームの声
28. 移⾏した後の開発チームの声 実はまだ移⾏中…
29. Sansan Builders Box - Lambdaのデプロイを改善したい - TerraformはLambda関数だけ構築、コードは管理していない - Terraform適⽤のパイプライン - GitHubのPull RequestやMergeを起因にplan, applyを実⾏したい 今後やりたいこと