Upgrade to Pro — share decks privately, control downloads, hide ads and more …

サービス開発のインフラ構築事情/environment construction example for DevOps

サービス開発のインフラ構築事情/environment construction example for DevOps

2021/3/19開催のイベント TIS Developers Night( https://tidev-meetup.connpass.com/event/199990/ )での発表資料です。

Toru Nagashima

March 23, 2021
Tweet

Other Decks in Technology

Transcript

  1. © 2021 TIS Inc. 2 自己紹介 • 長島 徹(ながしま とおる)

    • テクノロジー&イノベーション本部 アプリケーション開発部 所属 – 全社横断で事業部門と協業し技術支援を行う部門 • 業務 – バックエンドのアプリケーションアーキテクトとして中~大規模の案件を担当 • Java、Spring、Nablarch • 金融、決済系多め – Elastic Stack を使ってサービスの状態を可視化 https://japan.zdnet.com/extra/tis_202003/35151190/
  2. © 2021 TIS Inc. 3 目次 • サービス概要 • 技術支援のきっかけ/背景

    • 開発現場での課題・悩み • 改善に向けた取り組み • まとめ
  3. © 2021 TIS Inc. 7 画面イメージ ESG投資に使われる Environment(環境) Social(社会) Governance(ガバナンス=企業統治)

    別に開示充足率を出してくれる 昨年度からの変動も出る 何が嬉しいか ・投資家(機関投資家)にとって は投資の判断基準になる。 ・企業にとっては統合報告書の書 き方(見られ方)や経営判断につ ながる
  4. © 2021 TIS Inc. 8 アーキテクチャ概要 Internet User 正規化基盤 (Serverless)

    Web Application 非財務情報を 収集・分類 報告書 データ連携 参照・点検 投資期間 企業担当者
  5. © 2021 TIS Inc. 9 技術支援をするきっかけ • 新規サービスを作りたい。 今後も新しいサービスを立ち上げていきたい。 •

    既存サービスを運用する中で以下のような解決したい 課題・悩みがある – 新規にサービスを立ち上げるのに時間がかかる – システムの改修に時間がかかる – EC2 を使って個別にシステム構築しているので運用が大変 新技術に挑戦したいが何から手をつけたらいいか分からない →今後のサービス開発に向けて 基盤面の標準化、再利用性向上を図る
  6. © 2021 TIS Inc. 11 既存サービスのよくある構成 • EC2 にミドルウェアのインストール・設定をする •

    オンプレと同じような感じで構築 Public subnet AWS Cloud Private subnet Load Balancer Web Server Application Server Database Server Cache Server
  7. © 2021 TIS Inc. 12 開発現場での課題・悩み ~環境構築コスト~ • 環境を増やすのは大変 –

    コピーに頼ると設定をミスる – 現状の設定を知る方法は中身を見るしかない (ドキュメントが最新化されておらず、乖離してる) Public subnet AWS Cloud Private subnet LB Web AP DB Cache 環境A Public subnet AWS Cloud Private subnet LB Web AP DB Cache 環境B Web AP DB Cache コピーだけでは無理…
  8. © 2021 TIS Inc. 13 開発現場での課題・悩み ~環境準備のリードタイム~ • 開発をするには本番環境以外にも環境が必要 –

    ステージング/QA – テスト※開発計画次第で複数必要になる – 開発 • 本番環境が使えるようになるまでに時間がかかる – テスト ⇒ ステージング ⇒ 本番といった順番で作ることが多い – インフラ構築した後でアプリ開発者が使えるので、使えるよう になるまでに時間がかかる テスト ステージング 本番 よくある構築順序
  9. © 2021 TIS Inc. 14 • 環境が増えるとメンテナンスが大変 – 環境数×インスタンス数でメンテナンス対象が増える –

    OS、ミドルウェアへのパッチ、設定変更、不要データ削除 開発現場での課題・悩み ~メンテナンス~ Public subnet Private subnet テスト ステージング/QA ・・・ Public subnet Private subnet Public subnet Private subnet 本番 Public subnet Private subnet
  10. © 2021 TIS Inc. 15 開発現場での課題・悩み ~デプロイ~ • アプリが環境で動くまでに時間がかかる –

    ローカルでは動くけど環境が変わると動かない – CI/CD は後回し – デプロイは手作業。属人化 エンジニア Commit /Push 本番 Test & Build アプリ 生成 デプロイ ステージング テスト
  11. © 2021 TIS Inc. 19 マネージドサービスを活用したアーキテクチャ設計 • Epona を参考に検討 –

    環境構成 (デリバリー環境、ランタイム環境) – 参考にした pattern • cacheable_frontend • public_traffic_container_service • cd_pipeline_backend • cd_pipeline_frontend • users • Roles • アプリケーションはコンテナ化
  12. © 2021 TIS Inc. 20 価値に直結しない運用コストを削減する ~効果~ • マネージドサービスを使用することでの利点 –

    OS/ミドルウェアのパッチなどから解放された ※コンテナイメージの脆弱性チェックや対応は必要 – インストールなどが不要なのですぐに使える。 (開発を始めるまでが早い) • 気づき、今後への課題 – 覚えることが多い。使ってみないと分からない – トータルのリソースは増えた!? (コンソールから手でポチポチやってると管理が複雑になりそ う)
  13. © 2021 TIS Inc. 23 IaC(Infrastructure as Code) に挑戦 •

    AWS CloudFormation を使用 – AWS を使うことが決まってた – Terraform よりも学習コストが低そうだった • 基本的には勉強しながらトライ&エラー • 環境毎に変更する必要がある設定や、課金に影響する設 定は環境作成時に指定できるよう実装 使うサービスの 学習& 手作業でやって みる CloudFormation 書く 動かしてテスト 環境構築 に使用
  14. © 2021 TIS Inc. 24 無駄にお金を使わないように環境メンテナンス • 環境は必要になった時に作成 • 使い終わって不要になった環境は削除

    • 構成変更があった場合はすぐに対応して作り直し 環境の作成削除方針 … … … 作成/削除 ・・・ 環境差分 パラメーター
  15. © 2021 TIS Inc. 25 オンデマンドに環境構築 ~効果~ • IaC(Infrastructure as

    Code) をやることのメリット – 環境をすぐに増やせる • 人系のミスが減る • 属人化しない • 開発計画の変更にも対応しやすい (「テスト環境が追加で必要」とかに対応しやすい) – 不要な環境を消すことに対するハードルが低くなる • お金を無駄にしない – 環境面のブラックボックス感が減る (「あーこの環境こんな設定だったんだ…」系) – 作成したドキュメント量は減った
  16. © 2021 TIS Inc. 26 オンデマンドに環境構築 ~効果~ • 気づき、今後への課題 –

    覚えることは多い (前提知識が少なすぎた) – 1環境目を作るのはそれなりに時間かかる (コード化する分時間もかかる) – 「ここは手作業でいいか」という思いになることがある それに負けない気持ちは必要。 – メンテナンス/保守のやり方を定められていない • サービスイン前は作って壊してを繰り返していたけど、 これからはそうもいかないかも
  17. © 2021 TIS Inc. 29 デプロイパイプラインの自動化 • システム開発や改修にかかる期間を短縮するために デプロイパイプライン(CI/CD)を自動化する –

    エンジニアが開発に注力するために以下を自動化 • ビルド • テスト • リリース • デプロイ – 自動化することによってリリースのハードルを下げる – 継続的に環境にデプロイして検証を行い、問題の検知を早める
  18. © 2021 TIS Inc. 30 CI (継続的インテグレーション) • コードの変更をトリガーにして Test

    や Build を実行 • main ブランチに取込まれた修正はコンテナイメージを 作成して ECR にプッシュする デリバリー環境 Build & Test エンジニア Commit/Push Review フロントエンド 資材 ECR S3 アプリ
  19. © 2021 TIS Inc. 31 CD (継続的デリバリー) ECRにイメージが push されたら各環境の

    CodePipeline が実行される ※本番環境を自動デプロイしたくないので自動的に実行するかは環境 毎に変えている。 デリバリー環境 コンテナイメージの push テスト or ステージング環境 デプロイ 本番環境 デプロイ 実行 実行
  20. © 2021 TIS Inc. 32 ランタイム環境へのデプロイ(詳細) AWS CodePipeline でデプロイ順序を制御。 デリバリー環境の資材をランタイム環境にデプロイする。

    1. DBマイグ レーション 2. フロントエンド 資材配置 3. デプロイ (Blue/Green) DBマイグレーション コンテナ S3 (デリバリー環境) S3 (ランタイム環境) アプリケーション コンテナ S3 (ランタイム環境) デリバリー環境 ランタイム環境 Fargate
  21. © 2021 TIS Inc. 33 開発サイクルの高速化 ~効果~ CI/CD を自動化することで開発に注力できる –

    環境に反映するまでの時間が短縮(すぐに確認できる) – 手作業でやっていた時間を開発に充てられる – 環境間の差分が発生しにくい(問題が減る) ▪After ▪Before 自動 手動 自動
  22. © 2021 TIS Inc. 34 まとめ ~評価~ 今回の取り組みは「非財務情報参照・点検サービス」のよ うなサービス開発には以下の点で効果があった •

    付加価値の向上に注力できる • 環境面が開発スケジュールに影響しない 「今後のサービス開発に向けて基盤面の標準化、再利用性 向上を図る」に対しては以下の成果 • 環境構成(デリバリー環境、ランタイム環境)の標準化 • デプロイパイプラインの標準化 • 再利用可能な CloudFormation
  23. © 2021 TIS Inc. 35 まとめ ~今後に向けた課題~ • 今回の取り組みは継続的に開発する場合は「あたりま え」に備えているべき

    – デプロイパイプライン – 環境をオンデマンドに作る • 前提知識をそれほど持っていない人が1から考えるのは、 かなり大変だった – 使ってみて覚えるものが多い。 – どのようなクラウドリソースを使ったらよいのか、組み合わせ たらよいのかわからない ⇒これらの問題を解決するのは「Epona」!!
  24. © 2021 TIS Inc. 36 DevOps環境構築キット(Epona)とは 自社サービス用のDevOps用環境をオンデマンドで 構築できるツールキット • サービスを運用できる本番環境

    • 本番環境と同様の構成を持つテスト環境/ステージング環境 • チーム開発が可能な開発環境 ターゲットとするクラウドサービス • Amazon Web Services (AWS) ▪2020年度 ツールキットの提供する「モジュール」を 組み合わせることで、様々なサービス用環境を実現できます