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

© 2019, Amazon Web Services, Inc. or its affiliates. All
rights reserved. T O K Y O 2 0 1 9 . 1 0 . 0 3 - 0 4 マイクロサービスを支えるインフラアーキテクチャ株式会社メタップス本社開発グループ SREシニアエンジニア山北尚道 G - 1

rights reserved. 会社概要 - 株式会社メタップス • 企業理念: テクノロジーでお金と経済のあり方を変える • 設立: 2007年9月 • 従業員数: 323人 (2019年9月末時点)

rights reserved. 自己紹介 • 名前 • 山北尚道 • 所属 • 本社開発グループ SREシニアエンジニア • メタップス新規事業開発責任者 • 経歴 • ベトナムでのオフショア開発事業 • GitHub • https://github.com/naomichi-y/

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

rights reserved.

rights reserved. pring - 株式会社pring

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

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

rights reserved.

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

rights reserved. マイクロサービス化への移行設計 1. 現状のシステム構成分析 2. アーキテクチャの再設計 3. データベースの再設計 4. インフラの再設計 5. アプリケーションの再設計

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

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

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

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

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

rights reserved. 2.アーキテクチャの再設計 - AWS Well-Architected

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

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

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

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

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

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

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

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

rights reserved. 4.インフラの再設計 - AWSで利用中のサービス

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

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

rights reserved. 5.アプリケーションの再設計 - Cognitoへの移行

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

rights reserved. 5.アプリケーションの再設計 - メッセージ基盤

rights reserved.

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

rights reserved. Amazon ECSの運用 • メタップスでは2016年よりAmazon ECSの運用を開始 • ECSの運用状況 • 稼働システム数: 26 • クラスタ: 50 • サービス: 約200

rights reserved. Amazon ECS - クラスタ構成

rights reserved. • アプリケーションクラスタから集約したログをログクラスタで分析 • ログレベルに合わせて重要なメッセージはSlackに通知 • 整形したログをElasticsearchやS3に配送ログの可視化 - Kibana

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

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

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に対応

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

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分

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

rights reserved. イベント監視の通知

rights reserved.

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

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

rights reserved. チケットペイ - 株式会社メタップスペイメント • チケット販売サービス • 初期契約料、イベント登録料、紙代など全て無料 • インフラ構成管理の導入により、オンプレからAmszon ECSに移行

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

rights reserved. 総括 - 構成管理の重要性 • コード再利用によるインフラ構築コストの削減 • コード共有に伴う技術共有の活発化 • エンジニアのインフラスキルの向上

rights reserved. 総括 - 構成管理の改善イテレーション

rights reserved.

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

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

rights reserved. SREとしてメタップスグループのインフラ基盤を支えてくれる方、エンジニアとしてサービスに興味を持ってくださった方! 是非話を聞きにきてください! career@metaps.com

rights reserved. テクノロジーでお金と経済のあり方を変える

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

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

More Decks by Naomichi Yamakita

Other Decks in Technology

Featured

Transcript