CloudNativeなサービス用環境を構築するツールキット Eponaを作った/toolkit to create cloud-native environment for our services

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2020 TIS Inc. 2 自己紹介 • 木利友一 (@kiririmode) • 経歴 – 2015年 TIS転職 • 主としてバックエンドのアプリケーションアーキテクトとして、プロジェクトのリードやスクラムマスター – Java – Golang、Bitcoin、gRPC – 2018年育児休業（今日は子供の声がBGMとして入ります) – 2020年度よりテクノロジー&エンジニアリングセンターへ異動 • AWS、Terraform • Blog: 理系学生日記

Slide 3

Slide 3 text

© 2020 TIS Inc. 3 Epona 自社サービス用のCloudNativeなDevOps用環境をオンデマンドで構築できるツールキット • サービスを運用できる本番環境 • 本番環境と同様の構成を持つテスト環境/ステージング環境 • チーム開発が可能な開発環境ターゲットとするクラウドサービス • Amazon Web Services (AWS) ツールキットの提供する「モジュール」を組み合わせることで、様々なサービス用環境を実現できます

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2020 TIS Inc. 5 Epona • Epona – Terraformモジュール+ Guide を含むリポジトリ – https://gitlab.com/eponas/epona • Getting Started – Eponaを組み込んだ環境構築スクリプト用リポジトリ • Eponaはモジュール群なので、それを実際に組み込んだ一連のTerraform構成ファイル – https://gitlab.com/eponas/epona_aws_getting_started • Epona AWS Getting Starter (公開予定) – Terraform BackendやEponaの初期適用をサポートするCLIツール – https://gitlab.com/eponas/epona-aws-starter-cli • Fintan – https://fintan.jp/?p=6330

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2020 TIS Inc. 7 これまでの課題 • サービスを動かせる環境の調達や構築に時間がかかる • 素早くサービスを立ち上げたいのに、どのようなクラウドリソースを使ったらよいのか、組み合わせたらよいのかわからない • サービスの調査や環境の立ち上げに時間がかかる • サービスを立ち上げてはみたものの利用者の評価がわからない • システムの状況が把握できない。ログやデータベースを参照する必要があり、必要な時にタイムリーに確認できない。 • サービスの価値向上に時間を使いたいのに、セキュリティパッチ適用や監視構築といった価値に直結しない作業に時間が吸い取られている • 今の環境がどうやってつくられたのか分からず、サービスの要求に合わせて変更していくのが難しくなる • 環境構築手順が陳腐化しており、テストや検証などのために新しく環境を用意することが困難

Slide 8

Slide 8 text

© 2020 TIS Inc. 8 これまでの課題 • サービスを動かせる環境の調達や構築に時間がかかる • 素早くサービスを立ち上げたいのに、どのようなクラウドリソースを使ったらよいのか、組み合わせたらよいのかわからない • サービスの調査や環境の立ち上げに時間がかかる • サービスを立ち上げてはみたものの利用者の評価がわからない • システムの状況が把握できない。ログやデータベースを参照する必要があり、必要な時にタイムリーに確認できない。 • サービスの価値向上に時間を使いたいのに、セキュリティパッチ適用や監視構築といった価値に直結しない作業に時間が吸い取られている • 今の環境がどうやってつくられたのか分からず、サービスの要求に合わせて変更していくのが難しくなる • 環境構築手順が陳腐化しており、テストや検証などのために新しく環境を用意することが困難

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2020 TIS Inc. 10 サービスの調査や環境の立ち上げに時間がかかる Eponaによって何が解決できるのか • Eponaの提供するモジュールを適用すれば、「データベース」、「CDパイプライン」、「ログ収集」といったユースケースを実現できます。ネットワークデータベースコンテナランタイムフロントエンドランタイム Webアプリケーションファイアウォールログ収集仮想セキュアルーム VPC RDS ALB+ECS CloudFront+S3+Lambda@Edge WAF Datadog+Lambda Workspaces+Directory Service ユーザ・権限 IAM 提供するモジュール群 (一部) デプロイメントパイプライン CodePipeline+CodeDeploy CodePipeline+CodeBuild どのクラウドリソースを使い組み合わせたらよいのかわからないサービスを動かせる環境の調達や構築に時間がかかるサービスを動かせる環境の調達や構築に時間がかかる

Slide 11

Slide 11 text

© 2020 TIS Inc. 11 Eponaによって何が解決できるのか「Amazon QuickSight の新しい API とテーマ機能で、分析をさらに進化させる」（https://aws.amazon.com/jp/blogs/news/evolve-your-analytics-with-amazon-quicksights-new- apis-and-theming-capabilities/）2020年11月13日 23時時点の最新版を取得サービスを立ち上げてはみたものの利用者の評価がわからないシステムの状況が把握できない。必要な時にタイムリーに確認できない • KPIやシステムメトリクスを可視化することによって、リアルタイムにサービスやシステムの状態を把握できるようになります

Slide 12

Slide 12 text

© 2020 TIS Inc. 12 Eponaによって何が解決できるのか価値に直結しない作業に時間が吸い取られている価値に直結しない作業に時間が吸い取られている • マネージドサービスやSaaSを積極的に利用することで、セキュリティパッチ適用、モニタリングシステムの構築といった作業から開発チームを開放します • それにより、顧客満足度に直結する「魅力的品質」の向上に集中できます「狩野モデルと商品企画」（https://www.juse.or.jp/departmental/point02/08.html） 2020年11月13日 23時時点の最新版を取得差別化できない当たり前品質はマネージドサービス、SaaSに任せる • 「作り込む」のではなく、マネージドなサービスを積極採用。開発チームを「お守り」から解放する • SaaSはEponaで基本的な使い方をガイディングサービス開発で集中すべき領域

Slide 13

Slide 13 text

© 2020 TIS Inc. 13 Eponaによって何が解決できるのか今の環境の構築方法が分からず、サービスの成⾧に合わせた変更が困難環境構築手順が陳腐化し、新しく環境を用意することが困難 • どのような操作で当該環境が実現されているのかをコードから追うことができます • コードレビューやバージョン管理等、これまでのソフトウェアエンジニアリングの知見がインフラ環境にも適用でき、品質向上に貢献します review discussion $ terraform apply

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© 2020 TIS Inc. 15 使い方 1. ユースケースに応じ、使いたいモジュールを選ぶ – Eponaはユースケース毎のモジュール集です 2. モジュールの入力パラメータを設定する – ガイド上の入力パラメータをご参照ください 3. 適用する PJのユースケースに合わせて選択 Epona • CPUは4つ • メモリは1GB • ヘルスチェックのエンドポイントは /health Etc. ガイド $ terraform apply (snip) apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Slide 16

Slide 16 text

© 2020 TIS Inc. 16 Eponaのコンセプト • Self-Service – サービスチームの自律性を重視し、サービスチーム自らが開発・運用を行うための環境を構築する手段を提供します • Operation-Less – 価値提供に直接結びつかないシステム自体の運用に煩わされることのないよう、SaaS、マネージドサービスを積極的に採用します • Switchable – 環境がサポートする機能はできる限り疎結合にし、サービス開発者による無効化、別手段への切り替えを容易にします

Slide 17

Slide 17 text

© 2020 TIS Inc. 17 全体アーキテクチャ (AWS) • AWSのマルチアカウント構成を基本とした環境 – 各自社サービスごとにマルチアカウント環境を構成 • Shared型ではない、サービス固有の環境 Runtime環境本番環境、ステージング環境等のサービスが稼働する環境。個々の環境がAWSアカウント1つに対応する Delivery環境 Runtime環境に共通するデリバリの仕組み、 IAMユーザ等を配置する環境 SaaS群 GitLab、Slack or Microsoft Teams、 Datadog、PagerDutyと連携

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2020 TIS Inc. 19 フロントエンドホスト環境(cacheable_frontend) SPAをホストするフロントエンド用ランタイム • Amazon S3に静的コンテンツを配置 • Amazon CloudFront経由でインターネット公開 • Lambda@Edgeでセキュリティ系ヘッダを付与 See: https://gitlab.com/eponas/epona/-/blob/v0.2.1/guide/patterns/aws/cacheable_frontend.md

Slide 20

Slide 20 text

© 2020 TIS Inc. 20 フロントエンドコンテンツの継続的デリバリ(cd_pipeline_frontend) SPAの継続的デリバリ • Delivery環境のS3への静的コンテンツ配置をトリガーに起動 • EventBusでRuntime環境にCWE を伝搬させ、CodePipelineをキック • CodePipeline + CodeBuildで OriginのS3バケットに静的コンテンツを配置 See: https://gitlab.com/eponas/epona/-/blob/v0.2.1/guide/patterns/aws/cd_pipeline_frontend.md

Slide 21

Slide 21 text

© 2020 TIS Inc. 21 バックエンドホスト環境(public_traffic_container_service) コンテナ化されたアプリケーションのホスト環境 • AWS Fargateでコンテナをホスト • 前段にALBを配置 • DNSレコードやSSL/TLS証明書への対応 See: https://gitlab.com/eponas/epona/-/blob/v0.2.1/guide/patterns/aws/public_traffic_container_service.md

Slide 22

Slide 22 text

© 2020 TIS Inc. 22 サポートするアクティビティ DevOpsを実現するため、以下のアクティビティをサポートします – コミュニケーション – ITS/BTS – VCS Provider – デプロイメントパイプライン – バックアップ – セキュアな本番アクセス – インフラセキュリティ – モニタリング各アクティビティの詳細は https://eponas.gitlab.io/epona/guide/activities/をご参照ください

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2020 TIS Inc. 26 SIとDevOps SIer – 受託開発型中心の情報システム開発 – 多重下請構造我々が直面しているもの（※個人の感想です） • 求められているシステムを確実かつ効率良く完成する価値 • 求められているものがわからない中で、それを素早く見つけ改善していく価値「令和元年版情報通信白書」（https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r01/pdf/index.html）どちらの価値を提供するかで組織構造も戦略も異なる (bi-modal) 双方への対応【これまでのSIer】【これからのSIer】