PowerPoint プレゼンテーション

(1)

T O K Y O

2

0

1

9 .1

0 .0

3 -04

マイクロサービスを支える

インフラアーキテクチャ

株式会社メタップス

本社開発グループ SREシニアエンジニア

山北尚道

G - 1

(2)

会社概要 - 株式会社メタップス

• _{企業理念: テクノロジーでお金と経済のあり方を変える}

• _{設立: 2007年9月}

(3)

会社概要 - 株式会社メタップス

• _{企業理念: テクノロジーでお金と経済のあり方を変える}

• _{設立: 2007年9月}

(4)

自己紹介

• 名前

• 山北尚道

• 所属

• _{本社開発グループ SREシニアエンジニア}

• メタップス新規事業開発責任者

• 経歴

• ベトナムでのオフショア開発事業

• _GitHub

• https://github.com/naomichi-y/

(5)

Agenda

1. 事例紹介 - pring

• モノリシックからマイクロサービスへの移行

• マイクロサービスを支えるインフラアーキテクチャ

2. 構成管理の応用事例

• re:shine / miime / チケットペイ / Capy

3. 今後のロードマップ

(6)

(7)

(8)

新しい形のお金コミュニケーションアプリ

プリンの主な機能

• 個人間での送受金

• 店舗での支払い

• 銀行口座間の資金移動

• _{セブン銀行ATMで現金チャージ / 出金}

ポイント

• すべての機能が手数料無料

• チャット感覚で気軽にお金のやりとりが可能

• 「ひらがな」を活用した、感覚的に操作しやすいUI

(9)

技術構成 (2017年)

構成

パブリッククラウド

AWS (EC2 / RDS / ElastiCacheなど)

監視

Mackerel

フロントエンド

• ユーザアプリ

• Cordova

• 加盟店向けアプリ

• Kotlin

• Swift

バックエンド

PHP / Node.js

(10)

(11)

マイクロサービス化に至る経緯

• システム構成を分析

• フレームワーク上の問題や、クラウドネイティブに適さないアプリケーション設計、スケール

困難なインフラ運用など問題が多数見つかる

• 今後サービスをスケールする上でシステムの再設計が必要と判断

• 改修ポイント

• インフラ

• クラウドネイティブに適したインフラ設計

• AWSアカウントレベルで既存環境と構成を分離

• アプリケーション

• 開発言語の再選定

• モノリシックな構成からマイクロサービスへのリプレース

(12)

マイクロサービス化への移行設計

1. 現状のシステム構成分析

2. アーキテクチャの再設計

3. データベースの再設計

4. インフラの再設計

5. アプリケーションの再設計

(13)

1. 現状のシステム構成分析 - インフラ

✓

将来的なトラフィック増加に伴うスケーリング方針が定義されているか

✓

_{AWSが推奨する運用設計がされているか}

✓

インフラ構成を安全に変更できる管理体制となっているか

✓

データ分析のための基盤が整備されているか

✓

リソース監視が適切に行われているか

✓

情報セキュリティマネジメント

(14)

1. 現状のシステム構成分析 - アプリケーション

✓

_{AWSに適したアーキテクチャが採用されているか}

✓

_{DRYの原則が守られているか}

✓

アプリケーションはスケールしやすい構成か

✓

_{SQLアンチパターンの検証}

✓

コードレビュー、テストのポリシー

✓

_{Gitの運用、デプロイフロー}

(15)

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}

(16)

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

• _{AWS活用のためのベストプラクティス集}

• _{5つの柱、46の質問}

• 運用上の優秀性

• セキュリティ

• 信頼性

• パフォーマンス効率

• コストの最適化

• ホワイトペーパー

• https://aws.amazon.com/jp/architecture/well-architected/

(17)

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

• チェックリストの例

✓

データのアクセスパターンを考慮しているか

✓

疎結合なアーキテクチャを採用しているか

✓

ネットワーク設定について構成管理ツールなどを活用して自動化しているか

• _{2018年11月、Well-Architected Toolリリース}

• _{AWSマネージメントコンソールから開発者自身が}

Q&A形式でシステムのチェックを行うことができる

(18)

(19)

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

• 全ての項目に則る必要はあるか?

• 内容を理解した上で、ビジネスレベルでの判断を行う

• ベストプラクティスに適合しないことによるリスクや改善点を認識し、チームで共有する

• レビューは一度だけではなく、定期的に実施することでより優れた設計

を維持することができる

• Well-Architected自体もAWSの進化に伴いアップデートされる

(20)

2.アーキテクチャの再設計 - Twelve-Factor App

• クラウドネイティブアプリケーションのためのベストプラクティス集

• _{2012年にHerokuのエンジニアが提唱}

• 特定のプログラミング言語やインフラに依存せず適用することができる

• _{Beyond the Twelve-Factor App}

(21)

2.アーキテクチャの再設計 - Twelve-Factor App

I. コードベース

バージョン管理されている1つのコードベースと複数

のデプロイ

II. 依存関係

依存関係を明示的に宣言し分離する

III. 設定

設定を環境変数に格納する

IV. バックエンドサービス

バックエンドサービスをアタッチされたリソースとし

て扱う

V. ビルド、リリース、実行

ビルド、リリース、実行の3つのステージを厳密に分

離する

VI. プロセス

VII. ポートバインディング

ポートバインディングを通してサービスを公開する

VIII. 並行性

プロセスモデルによってスケールアウトする

IX. 廃棄容易性

高速な起動とグレースフルシャットダウンで堅牢性を

最大化する

X. 開発 / 本番一致

開発、ステージング、本番環境をできるだけ一致させ

た状態を保つ

XI. ログ

ログをイベントストリームとして扱う

XII. 管理プロセス

管理タスクを1回限りのプロセスとして実行する

(22)

2.アーキテクチャの再設計 - SAP

• _{SAP: Strangler Application Pattern}

• 既存のシステムを段階的に新システムに移行する手法

• _{2004年、Martin Fowlerが提唱}

• 稼働中のシステムを一度にリプレースすることは困難

(23)

2.アーキテクチャの再設計 - 管理画面移行の例

• _{元々EC2で動いていた管理画面を新AWSアカウントのECSに移行}

• _{Re-Platform (lift-tinker-shift) パターン}

(24)

3. データベースの再設計

• テーブルの正規化

• テーブル、フィールドなどの命名規則の統一

• サロゲートキー、外部参照制約、データ型の見直し

• _{SQLアンチパターンの解決}

• EAV (Entity-Attribute-Value) の正規化

• 共有データベースの分離

• マイクロサービスごとにデータベースを分離して管理

• _{分析時点で150超のテーブルがあり、現時点では}

スキーマの分割が困難と判断

• 新規に追加される機能はDBを分割した設計を採用

(25)

4.インフラの再設計 - Terraformによる構成管理

• _{AWSアカウントを新設}

• ほぼ全てのインフラリソースをコード管理

• AWS / GitHub / Datadog

• _{AWS Well-Architectedのルールに則った設計を目指す}

• メリット

• リソースの変更をGitHub Issueベースで管理できる

• レビュー体制を取ることで、構成変更のダブルチェックが可能

• AWS Configと組み合わせることで構成の更新追跡が容易に

(26)

4.インフラの再設計 - AWSネットワーク構成

• _VPCの設計

• _{アプリケーションVPC}

• _{開発環境 / ステージング環境 / 本番環境}

• _管理VPC

• 踏み台、デプロイサーバなど

• 設計ポリシー

• _{管理VPCからアプリケーションVPCに接続可能}

• アプリケーションVPC間の接続は不可

• 外部への通信はNAT Gatway経由

• VPCフローログの有効化

(27)

(28)

5.アプリケーションの再設計 - 設計ポイント

• 開発言語の見直し

• _{PHPからRuby (Ruby on Rails + Trailblazer) への移行}

• _{APIファースト開発}

• APIを初めに設計することで、Webやアプリとの調整が取りやすくなる

• Open APIによる設計

• _{API再設計に伴い、エンドポイントを総入れ替え}

• クラウドネイティブに適したデザインパターンの適用

• APIゲートウェイ

• サービスディスカバリ

• _{フェデレーションID}

• 集約ログなど

(29)

5.アプリケーションの再設計 - 認証基盤

• _{Amazon Cognitoの採用}

• _{AWSが提供するセキュアでスケーラブルなIDプロバイダ}

• _{OAuth 2.0、SAML 2.0、OpenID ConnectなどのフェデレーションIDを提供}

• _{Cognitoの導入によって得られた成果}

(30)

(31)

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

• コミュニケーションアプリゆえ、主機能となるチャットの役割が重要

• データベースに求められる要件

• 高スケーラビリティ

• 高信頼性

• 高可用性

• _{AWS DynamoDBの採用のポイント}

• 規模に関係なく数ミリ秒台のパフォーマンスを実現

• 全データを標準で暗号化

• フルマネージドのため、標準でオートスケーリングや継続的バックアップに対応

(32)

(33)

(34)

Amazon ECSの運用

• _{ECS (Elastic Container Service)}

• コンテナ化されたアプリケーションを本番環境で実行するオーケストレーションサービス

• ECSは2つの起動方法をサポート

• EC2: ECS内部でEC2を利用

• _{Fargate: インスタンス管理はフルマネージド}

• _{同様のサービスとしてはKubernetes (k8s) がある}

(35)

Amazon ECSの運用

• _{メタップスでは2016年よりAmazon ECSの運用を開始}

• _{ECSの運用状況}

• _{稼働システム数: 26}

• クラスタ: 50

• サービス: 約200

(36)

(37)

• アプリケーションクラスタから集約したログをログクラスタで分析

• _{ログレベルに合わせて重要なメッセージはSlackに通知}

• _{整形したログをElasticsearchやS3に配送}

(38)

ECS運用Tips- 設計

• _{サービスディスカバリの活用 (AWS Cloud Map)}

• コンテナ間通信をDNSで解決

• サービスは機能単位で分割

• _{疎結合な構成。サービス間はAPIで通信}

• パスベースルーティングを用いたフォワード

• サービスごとのタスク数、リソース割当を調整

• 集約ログ

• ログクラスタとアプリケーションクラスタの関係性は1:n

(39)

ECS運用上の工夫 - デプロイ

• _{デプロイツール「genova」を内製で開発。OSSで公開}

• _{https://github.com/metaps/genova}

• 特徴

• GitHubと連携し、ECSタスクの作成からイメージビルド、ECRへのイメージプッシュ

• Run taskの実行や、サービス・タスクスケジュールのデプロイをサポート

• CLIデプロイのほか、GitHub Pushによる自動デプロイ、Slackを用いた対話形式のデプロイをサ

ポート

(40)

Fargateの運用 - 課題

• _{SSHが出来ない}

• docker execができないため、メモリリークなどの問題が発生した際のトラブルシュートが困難

• ログドライバがFluentdをサポートしていない

• _{サポートするログドライバはCloudWatch Logs、Splunkのみ}

• 2019年9月6日、「Amazon ECS and AWS Fargate FireLens Preview Program」という形でパブリック

プレビューが公開

(41)

セキュリティ対策の観点

• 課題

• 人為的ミスの防止

• 誤ったセキュリティグループの設定

• _{Amazon S3に対する不適切なバケットポリシーの適用など}

• 攻撃に対するリソースの保護

• プログラムの脆弱性を突いた攻撃 (XSS、OSコマンドインジェクションなど)

• DDoS攻撃など

• 解決策

• AWSセキュリティオートメーションツールの導入 (AWS WAF、Amazon GuardDutyなど)

• 外部による脆弱性診断など

(42)

すぐに始められるセキュリティ対策

概要

概算時間

Well-Architected Tool

アーキテクチャのレビュー

_1時間

Trusted Advisorの実行

セキュリティやパフォーマンスの観点から

_{AWSの推奨設定をレポート}

5分

GuardDutyの有効化

機械学習によるAWSリソースの異常検知 (コイ

_{ンマイニング、SSHブルートフォースなど)}

5分

CloudTrailの有効化

AWSアカウントのアクティビティを監視

5分

Configの有効化

AWSリソースの変更を監視

5分

WAFの有効化

Webアプリケーションに対する攻撃をブロッ

_{クするファイアウォール。DDoS攻撃にも対応}

10分

(43)

インフラのイベント監視

• _{AWSの各種サービスから出力されるログをLambdaで分析}

• _{WAFの攻撃検知}

• コンプライアンス違反のリソース

• _{EC2リタイアメント通知}

• _{重要度の高いイベントはSlackに通知}

• _{監視ツールはServerless Frameworkで実装}

• _{ログはAmazon Elasticsearch Serviceに配送}

(44)

(45)

(46)

re:shine - 株式会社メタップス

• 双方向のフリーランスマッチングプラットフォーム

• _{フリーランスや、副 (複) 業者向け}

• 週3日から可能、フリーランス型正社員という新しい雇用形態

• すべて無料のフリーランスマッチングプラットフォーム

• 企業向け

• フリーランスを活用したい企業のサポート

• 費用は紹介手数料の5%のみ

(無料キャンペーン中)

(47)

miime - 株式会社メタップスアルファ

• _{ゲームのキャラクターやアイテムを始めとしたデジタルアイテム (NFT)}

をユーザー同士で売買する場を提供

• ブロックチェーンを活用することで、売買が成立してすぐに支払いとデ

(48)

チケットペイ - 株式会社メタップスペイメント

• チケット販売サービス

• 初期契約料、イベント登録料、紙代など全て無料

(49)

CapyパズルCHAPTCHA - Capy株式会社様

• _{Webサイト、スマートフォンアプリなどにおける}

Botからの攻撃に対策するクラウド型サービス

• _{国内外の権威あるカンファレンスでの受賞は10以上}

• _{Capyが提供するJavaScriptをサイトに貼り付け、}

API連携に必要な情報をPOSTするだけで導入可能

• インフラ基盤をマルチクラウド化

• ECSを始め、インフラ監視基盤やデプロイツールを導入

(50)

総括 - 構成管理の重要性

• コード再利用によるインフラ構築コストの削減

• コード共有に伴う技術共有の活発化

(51)

(52)

(53)

メタップスにおける今後の課題 - SRE

• _{SRE: Site Reliability Engineering}

• ミッション

• ソフトウェア主導によるサービス品質の向上

• 主な仕事

• インフラの設計、構築

• 運用の最適化、自動化

• システムの監視、障害対応

• 課題

• アプリケーション監視 (APM)

(54)

メタップスにおける今後の課題 - ESC

• _{ESC: Engineer Steering Committee}

• ミッション

• 組織的なエンジニアリングの最適化

• 役割

• 全社的な開発 / 運用方針の決定

• 課題

• エンジニアの働きやすい環境づくり

• エンジニアの成長サイクルの確立

• 全社的なメディア露出の強化

(55)

SREとしてメタップスグループのインフラ基盤を支えてくれる方、

エンジニアとしてサービスに興味を持ってくださった方!

是非話を聞きにきてください!

[email protected]

(56)

PowerPoint プレゼンテーション

T O K Y O

2

0

1

9

.1

0

.0

3

-04

マイクロサービスを支える

インフラアーキテクチャ

株式会社メタップス

本社開発グループ SREシニアエンジニア

山北 尚道

G - 1

会社概要 - 株式会社メタップス

•

企業理念: テクノロジーでお金と経済のあり方を変える

•

設立: 2007年9月

会社概要 - 株式会社メタップス

•

企業理念: テクノロジーでお金と経済のあり方を変える

•

設立: 2007年9月

自己紹介

•

名前

•

山北 尚道

•

所属

•

本社開発グループ SREシニアエンジニア

•

メタップス新規事業 開発責任者

•

経歴

•

ベトナムでのオフショア開発事業

•

GitHub

•

https://github.com/naomichi-y/

Agenda

1.

事例紹介 - pring

•

モノリシックからマイクロサービスへの移行

•

マイクロサービスを支えるインフラアーキテクチャ

2.

構成管理の応用事例

•

re:shine / miime / チケットペイ / Capy

3.

今後のロードマップ

新しい形のお金コミュニケーションアプリ

プリンの主な機能

•

個人間での送受金

•

店舗での支払い

•

銀行口座間の資金移動

•

セブン銀行ATMで現金チャージ / 出金

ポイント

•

すべての機能が手数料無料

•

チャット感覚で気軽にお金のやりとりが可能

•

「ひらがな」を活用した、感覚的に操作しやすいUI

技術構成 (2017年)

構成

パブリッククラウド

AWS (EC2 / RDS / ElastiCacheなど)

山北尚道

_{企業理念: テクノロジーでお金と経済のあり方を変える}

_{設立: 2007年9月}

_{企業理念: テクノロジーでお金と経済のあり方を変える}

_{設立: 2007年9月}

山北尚道

_{本社開発グループ SREシニアエンジニア}

メタップス新規事業開発責任者

_GitHub

_{セブン銀行ATMで現金チャージ / 出金}

_{AWSが推奨する運用設計がされているか}

_{AWSに適したアーキテクチャが採用されているか}

_{DRYの原則が守られているか}

_{SQLアンチパターンの検証}

_{Gitの運用、デプロイフロー}