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を使った
   ステージング環境の再構築
   

   View Slide

2. #33tech
   

   View Slide

3. 藤⽥ ⻫（Hitoshi Fujita）
   DSOC Infrastructure Group
   - お仕事
   DSOCの名刺データ化システム、名寄システムのインフラ運⽤、改善
   - 趣味
   バスケットボール, TVゲーム
   - Twitter
   https://twitter.com/noobs_waneal
   - GitHub
   https://github.com/waneal
   

   View Slide

4. Sansan Builders Box
   ゴール
   - Terraformを使ったAWS環境構築で直⾯した課題を知ってもらう
   - AWSコスト、運⽤コストを最適化する⽅法を知ってもらう
   

   View Slide

5. Sansan Builders Box
   Agenda
   - 名寄システムについて
   - ステージング環境再構築
   - 構築で直⾯した課題
   - 今後やりたいこと
   

   View Slide

6. 名寄システムについて
   

   View Slide

7. Sansan Builders Box
   名寄とは？
   名
   寄
   Sansan株式会社
   藤⽥⻫
   会社と⼈物を識別する
   

   View Slide

8. Sansan Builders Box
   会社の名寄とは？
   ・会社：三三株式会社
   ・部署：営業部
   ・ドメイン：sansan.com
   ・会社：Sansan株式会社
   ・部署：営業部
   ・ドメイン：sansan.com
   ・会社：Sansan
   ・部署：営業部
   ・ドメイン：sansan.com
   ・会社：Sansan株式会社
   ・部署：スリー部
   ・ドメイン：threethree.com
   社名変更・合併
   通称・略称
   同名他社
   Sansan株式会社
   

   View Slide

9. Sansan Builders Box
   会社の名寄とSansan/Eightの関係
   DSOC (Data Strategy & Operation Center)
   Sansan、Eight を⽀える存在
   名寄システム
   データ化された
   名刺の会社情報
   名寄された
   会社
   

   View Slide

10. Sansan Builders Box
    AWSアカウント構成
    - 1つのAWSアカウントに複数システムが共存
    - 歴史的経緯あり
    - 各環境の利⽤⽤途
    - 本番環境
    - ステージング環境
    - 結合テスト
    - 本番と同じ構成
    - インスタンスタイプ、台数は異なる
    - 開発環境
    - 各種AWSサービスの検証
    

    View Slide

11. Sansan Builders Box
    インフラチームが抱える課題
    - コストが明確に分離できない
    - タグをもとにシステム毎に算出しているが完全とは⾔えない
    - ネットワークコストなど
    - 構成・権限の複雑化
    - IAMロール、Security Group, サブネットが複雑化
    

    View Slide

12. ある⽇、開発チームから相談が...
    

    View Slide

13. Sansan Builders Box
    リリース前のリハーサルの質を上げたい
    - ステージング環境はテストデータを利⽤
    - テストデータでの結合検証のみ
    - 会社の名寄の結果までは確認できていない
    - リハーサルの質を上げたい
    - 本番相応の会社データを利⽤してこれを実現
    - 会社データのため個⼈情報は含まれていない
    Sansan Builders Box
    
    
    
    
    - "%98
    - &*'.
    - -7$& !3
    
    - +/
    - 642 -98,(
    - -)105#
    
    

    View Slide

14. 本番環境・ステージング環境の
    課題を解決すべくインフラ再構築
    まずはステージング環境を再構築
    

    View Slide

15. Sansan Builders Box
    名寄せシステムのインフラを再構築
    - アカウントを分離
    - アカウント毎でコスト算出
    - 構成・権限をシンプルに
    - 開発効率向上
    - 各環境の役割変更
    - ステージング環境
    - リリース前リハーサル
    - 結合テスト
    - 開発環境
    - AWSサービス検証
    

    View Slide

16. Sansan Builders Box
    名寄せシステムのインフラを再構築
    今回の発表範囲
    - アカウントを分離
    - アカウント毎でコスト算出
    - 構成・権限をシンプルに
    - 開発効率向上
    - 各環境の役割変更
    - ステージング環境
    - リリース前リハーサル
    - 結合テスト
    - 開発環境
    - AWSサービス検証
    

    View Slide

17. ステージング環境再構築
    

    View Slide

18. Sansan Builders Box
    AWS環境をコード化
    - ⽬的
    - 本番環境構築の作業コストを削減
    - 環境間の設定差異をなくす
    - Terraformを採⽤
    - Hashicorp製オープンソースのインフラ構築ツール
    - インフラの状態を保持、冪等性がある
    - 社内での利⽤実績多数
    

    View Slide

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台に集約
    

    View Slide

20. Sansan Builders Box
    運⽤コストの最適化
    - Terraformのコードはアプリ・インフラ両⽅が書く
    - インフラチームの運⽤コスト削減
    - 全体の開発スピード向上
    - 現在はインフラチームの作業がボトルネックに
    - ステージング環境の起動はSlackから
    - Slackコマンド → 共有ボット⽤EC2 → EC2, RDS起動
    

    View Slide

21. 構築で直⾯した課題
    

    View Slide

22. Sansan Builders Box
    どうやって別アカウントのRDSを持ってくるか
    - RDS（Aurora）から週次でクローン作成
    - Auroraは2019/7/2よりアカウント間のクローンがサポート
    - CloudWatch Events + CodeBuild
    - クローンのほうがスナップショットからリストアするより安い
    - 本番のディスクを丸ごとステー
    ジングにコピー
    - ストレージコストが2倍
    リストア
    - コピーオンライト。本番との差
    分だけをステージングのディス
    クで持つ
    - 新規の書き込み分だけ費⽤がか
    かる
    クローン
    

    View Slide

23. Sansan Builders Box
    どこまでコード化するか
    - 全部Terraformで書きたい欲を抑える
    - 無理やりコード化するとメンテナンス性が低下する場合も
    - コード化しないと決めたもの
    - アプリケーション側だけで完結する部分
    - Parameter Store、Lambdaのコード
    - CloudFormation
    - Instance Schedulerで利⽤
    - コード化できなかった部分はドキュメントとして残す
    

    View Slide

24. Sansan Builders Box
    ディレクトリ構成をどうするか
    - システム毎に適したものを採⽤すべき
    - リソースをimmutable, mutableで分離
    - メリット
    - tfstateが別れているのでplan, applyが早い
    - オンデマンドなリソース構築が楽
    - デメリット
    - 依存関係を整理する必要がある
    - 環境毎の設定差異はtfvarsで定義
    - prod.tfvars, stg,tfvars, dev.tfvars
    - workspace毎に作成
    - 環境ごとでリソース要素が変わらないのでこの⽅法を選定
    

    View Slide

25. Sansan Builders Box
    ディレクトリ構成をどうするか
    

    View Slide

26. Sansan Builders Box
    Secretsをどうやって管理するか
    - データベースのパスワードやAPIキーなどをGitHubにアップしたくない
    - データソース: aws_ssm_parameterを利⽤
    ただし、tfstateファイルに平⽂で書き込まれるので注意
    tfstateファイルへのアクセス権限に気をつける
    

    View Slide

27. 移⾏した後の開発チームの声
    

    View Slide

28. 移⾏した後の開発チームの声
    実はまだ移⾏中…
    

    View Slide

29. Sansan Builders Box
    - Lambdaのデプロイを改善したい
    - TerraformはLambda関数だけ構築、コードは管理していない
    - Terraform適⽤のパイプライン
    - GitHubのPull RequestやMergeを起因にplan, applyを実⾏したい
    今後やりたいこと
    

    View Slide

30. View Slide