マイクロサービスを支えるインフラアーキテクチャ/microservice-infra-architecture

by Naomichi Yamakita

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda 1. 事例紹介 - pring • モノリシックからマイクロサービスへの移行 • マイクロサービスを支えるインフラアーキテクチャ 2. 構成管理の応用事例 • re:shine / miime / チケットペイ / Capy 3. 今後のロードマップ • SREチームの発足とこれからの展望

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 新しい形のお金コミュニケーションアプリプリンの主な機能 • 個人間での送受金 • 店舗での支払い • 銀行口座間の資金移動 • セブン銀行ATMで現金チャージ / 出金ポイント • すべての機能が手数料無料 • チャット感覚で気軽にお金のやりとりが可能 • 「ひらがな」を活用した、感覚的に操作しやすいUI

Slide 9

Slide 9 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 技術構成 (2017年) 構成パブリッククラウド AWS (EC2 / RDS / ElastiCacheなど) 監視 Mackerel フロントエンド • ユーザアプリ • Cordova • 加盟店向けアプリ • Kotlin • Swift バックエンド PHP / Node.js 外部連携サービス Firebase Cloud Messaging / Twilio

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. マイクロサービス化に至る経緯 • システム構成を分析 • フレームワーク上の問題や、クラウドネイティブに適さないアプリケーション設計、スケール困難なインフラ運用など問題が多数見つかる • 今後サービスをスケールする上でシステムの再設計が必要と判断 • 改修ポイント • インフラ • クラウドネイティブに適したインフラ設計 • AWSアカウントレベルで既存環境と構成を分離 • アプリケーション • 開発言語の再選定 • モノリシックな構成からマイクロサービスへのリプレース

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1.現状のシステム構成分析 - インフラ ü 将来的なトラフィック増加に伴うスケーリング方針が定義されているか ü AWSが推奨する運用設計がされているか ü インフラ構成を安全に変更できる管理体制となっているか ü データ分析のための基盤が整備されているか ü リソース監視が適切に行われているか ü 情報セキュリティマネジメント

Slide 14

Slide 14 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1.現状のシステム構成分析 - アプリケーション ü AWSに適したアーキテクチャが採用されているか ü DRYの原則が守られているか ü アプリケーションはスケールしやすい構成か ü SQLアンチパターンの検証 ü コードレビュー、テストのポリシー ü Gitの運用、デプロイフロー

Slide 15

Slide 15 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 • Infrastructure as Code • Terraform • Serverless Architecture • Amazon API Gateway • AWS Fargate • AWS Lambda • Best practice • AWS Well-Architected • The Twelve Factor App • Strangler Application Pattern • Framework • Ruby on Rails + Trailblazer • API • Open API • Identity as a Service • AWS Cognito • Chat message storage • Amazon DynamoDB

Slide 16

Slide 16 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - AWS Well-Architected • AWS活用のためのベストプラクティス集 • 5つの柱、46の質問 • 運用上の優秀性 • セキュリティ • 信頼性 • パフォーマンス効率 • コストの最適化 • ホワイトペーパー • https://aws.amazon.com/jp/architecture/well-architected/

Slide 17

Slide 17 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - AWS Well-Architected • チェックリストの例 ü データのアクセスパターンを考慮しているか ü 疎結合なアーキテクチャを採用しているか ü ネットワーク設定について構成管理ツールなどを活用して自動化しているか • 2018年11月、Well-Architected Toolリリース • AWSマネージメントコンソールから開発者自身が Q&A形式でシステムのチェックを行うことができる

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - AWS Well-Architected • 全ての項目に則る必要はあるか? • 内容を理解した上で、ビジネスレベルでの判断を行う • ベストプラクティスに適合しないことによるリスクや改善点を認識し、チームで共有する • レビューは一度だけではなく、定期的に実施することでより優れた設計を維持することができる • Well-Architected自体もAWSの進化に伴いアップデートされる

Slide 20

Slide 20 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - Twelve-Factor App • クラウドネイティブアプリケーションのためのベストプラクティス集 • 2012年にHerokuのエンジニアが提唱 • 特定のプログラミング言語やインフラに依存せず適用することができる • Beyond the Twelve-Factor App • Twelve-Factor Appのアップデート版

Slide 21

Slide 21 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - Twelve-Factor App I. コードベースバージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係依存関係を明示的に宣言し分離する III. 設定設定を環境変数に格納する IV. バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実行ビルド、リリース、実行の3つのステージを厳密に分離する VI. プロセスアプリケーションを1つもしくは複数のステートレスなプロセスとして実行する VII. ポートバインディングポートバインディングを通してサービスを公開する VIII.並行性プロセスモデルによってスケールアウトする IX. 廃棄容易性高速な起動とグレースフルシャットダウンで堅牢性を最大化する X. 開発 / 本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ XI. ログログをイベントストリームとして扱う XII. 管理プロセス管理タスクを1回限りのプロセスとして実行する

Slide 22

Slide 22 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - SAP • SAP: Strangler Application Pattern • 既存のシステムを段階的に新システムに移行する手法 • 2004年、Martin Fowlerが提唱 • 稼働中のシステムを一度にリプレースすることは困難 • 徐々にマイクロサービスな領域を増やしつつ、レガシーなコードを破棄していく

Slide 23

Slide 23 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2.アーキテクチャの再設計 - 管理画面移行の例 • 元々EC2で動いていた管理画面を新AWSアカウントのECSに移行 • Re-Platform (lift-tinker-shift) パターン • ALBのパスベースルーティングで旧環境 (/v1)、新環境 (/v2) を並行運用

Slide 24

Slide 24 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3. データベースの再設計 • テーブルの正規化 • テーブル、フィールドなどの命名規則の統一 • サロゲートキー、外部参照制約、データ型の見直し • SQLアンチパターンの解決 • EAV (Entity-Attribute-Value) の正規化 • 共有データベースの分離 • マイクロサービスごとにデータベースを分離して管理 • 分析時点で150超のテーブルがあり、現時点ではスキーマの分割が困難と判断 • 新規に追加される機能はDBを分割した設計を採用

Slide 25

Slide 25 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4.インフラの再設計 - Terraformによる構成管理 • AWSアカウントを新設 • ほぼ全てのインフラリソースをコード管理 • AWS / GitHub / Datadog • AWS Well-Architectedのルールに則った設計を目指す • メリット • リソースの変更をGitHub Issueベースで管理できる • レビュー体制を取ることで、構成変更のダブルチェックが可能 • AWS Configと組み合わせることで構成の更新追跡が容易に

Slide 26

Slide 26 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4.インフラの再設計 - AWSネットワーク構成 • VPCの設計 • アプリケーションVPC • 開発環境 / ステージング環境 / 本番環境 • 管理VPC • 踏み台、デプロイサーバなど • 設計ポリシー • 管理VPCからアプリケーションVPCに接続可能 • アプリケーションVPC間の接続は不可 • 外部への通信はNAT Gatway経由 • VPCフローログの有効化

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5.アプリケーションの再設計 - 設計ポイント • 開発言語の見直し • PHPからRuby (Ruby on Rails + Trailblazer) への移行 • APIファースト開発 • APIを初めに設計することで、Webやアプリとの調整が取りやすくなる • Open APIによる設計 • API再設計に伴い、エンドポイントを総入れ替え • クラウドネイティブに適したデザインパターンの適用 • APIゲートウェイ • サービスディスカバリ • フェデレーションID • 集約ログなど

Slide 29

Slide 29 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5.アプリケーションの再設計 - 認証基盤 • Amazon Cognitoの採用 • AWSが提供するセキュアでスケーラブルなIDプロバイダ • OAuth 2.0、SAML 2.0、OpenID ConnectなどのフェデレーションIDを提供 • Cognitoの導入によって得られた成果 • 認証基盤を外部化することで、開発者はビジネスロジックの実装にフォーカス出来た

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5.アプリケーションの再設計 - メッセージ基盤 • コミュニケーションアプリゆえ、主機能となるチャットの役割が重要 • データベースに求められる要件 • 高スケーラビリティ • 高信頼性 • 高可用性 • AWS DynamoDBの採用のポイント • 規模に関係なく数ミリ秒台のパフォーマンスを実現 • 全データを標準で暗号化 • フルマネージドのため、標準でオートスケーリングや継続的バックアップに対応

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Amazon ECSの運用 • ECS (Elastic Container Service) • コンテナ化されたアプリケーションを本番環境で実行するオーケストレーションサービス • ECSは2つの起動方法をサポート • EC2: ECS内部でEC2を利用 • Fargate: インスタンス管理はフルマネージド • 同様のサービスとしてはKubernetes (k8s) がある • AWSではEKS (Elastic Kubernetes Service) として提供

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ECS運用Tips- 設計 • サービスディスカバリの活用 (AWS Cloud Map) • コンテナ間通信をDNSで解決 • サービスは機能単位で分割 • 疎結合な構成。サービス間はAPIで通信 • パスベースルーティングを用いたフォワード • サービスごとのタスク数、リソース割当を調整 • 集約ログ • ログクラスタとアプリケーションクラスタの関係性は1:n

Slide 39

Slide 39 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ECS運用上の工夫 - デプロイ • デプロイツール「genova」を内製で開発。OSSで公開 • https://github.com/metaps/genova • 特徴 • GitHubと連携し、ECSタスクの作成からイメージビルド、ECRへのイメージプッシュ • Run taskの実行や、サービス・タスクスケジュールのデプロイをサポート • CLIデプロイのほか、GitHub Pushによる自動デプロイ、Slackを用いた対話形式のデプロイをサポート

Slide 40

Slide 40 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Fargateの運用 - 課題 • SSHが出来ない • docker execができないため、メモリリークなどの問題が発生した際のトラブルシュートが困難 • ログドライバがFluentdをサポートしていない • サポートするログドライバはCloudWatch Logs、Splunkのみ • 2019年9月6日、「Amazon ECS and AWS Fargate FireLens Preview Program」という形でパブリックプレビューが公開 • FireLensドライバ経由でFluentd / Fluentd Bitに対応

Slide 41

Slide 41 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. セキュリティ対策の観点 • 課題 • 人為的ミスの防止 • 誤ったセキュリティグループの設定 • Amazon S3に対する不適切なバケットポリシーの適用など • 攻撃に対するリソースの保護 • プログラムの脆弱性を突いた攻撃 (XSS、OSコマンドインジェクションなど) • DDoS攻撃など • 解決策 • AWSセキュリティオートメーションツールの導入 (AWS WAF、Amazon GuardDutyなど) • 外部による脆弱性診断など

Slide 42

Slide 42 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. すぐに始められるセキュリティ対策概要概算時間 Well-Architected Tool アーキテクチャのレビュー 1時間 Trusted Advisorの実行セキュリティやパフォーマンスの観点から AWSの推奨設定をレポート 5分 GuardDutyの有効化機械学習によるAWSリソースの異常検知 (コインマイニング、SSHブルートフォースなど) 5分 CloudTrailの有効化 AWSアカウントのアクティビティを監視 5分 Configの有効化 AWSリソースの変更を監視 5分 WAFの有効化 Webアプリケーションに対する攻撃をブロックするファイアウォール。DDoS攻撃にも対応 10分 Inspectorの有効化 EC2に診断用エージェントをセットアップして脆弱性を診断 30分

Slide 43

Slide 43 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. インフラのイベント監視 • AWSの各種サービスから出力されるログをLambdaで分析 • WAFの攻撃検知 • コンプライアンス違反のリソース • EC2リタイアメント通知 • 重要度の高いイベントはSlackに通知 • 監視ツールはServerless Frameworkで実装 • ログはAmazon Elasticsearch Serviceに配送

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. re:shine - 株式会社メタップス • 双方向のフリーランスマッチングプラットフォーム • フリーランスや、副 (複) 業者向け • 週3日から可能、フリーランス型正社員という新しい雇用形態 • すべて無料のフリーランスマッチングプラットフォーム • 企業向け • フリーランスを活用したい企業のサポート • 費用は紹介手数料の5%のみ (無料キャンペーン中)

Slide 47

Slide 47 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. miime - 株式会社メタップスアルファ • ゲームのキャラクターやアイテムを始めとしたデジタルアイテム (NFT) をユーザー同士で売買する場を提供 • ブロックチェーンを活用することで、売買が成立してすぐに支払いとデジタルアイテム (NFT) の所有権移転が同時に実行される仕組みを実現

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. CapyパズルCHAPTCHA - Capy株式会社様 • Webサイト、スマートフォンアプリなどにおける Botからの攻撃に対策するクラウド型サービス • 国内外の権威あるカンファレンスでの受賞は10以上 • Capyが提供するJavaScriptをサイトに貼り付け、 API連携に必要な情報をPOSTするだけで導入可能 • インフラ基盤をマルチクラウド化 • ECSを始め、インフラ監視基盤やデプロイツールを導入

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. メタップスにおける今後の課題 - SRE • SRE: Site Reliability Engineering • ミッション • ソフトウェア主導によるサービス品質の向上 • 主な仕事 • インフラの設計、構築 • 運用の最適化、自動化 • システムの監視、障害対応 • 課題 • アプリケーション監視 (APM) • 機械学習を用いたアラート検知

Slide 54

Slide 54 text

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. メタップスにおける今後の課題 - ESC • ESC: Engineer Steering Committee • ミッション • 組織的なエンジニアリングの最適化 • 役割 • 全社的な開発 / 運用方針の決定 • 課題 • エンジニアの働きやすい環境づくり • エンジニアの成長サイクルの確立 • 全社的なメディア露出の強化