• 検索結果がありません。

PowerPoint プレゼンテーション

N/A
N/A
Protected

Academic year: 2021

シェア "PowerPoint プレゼンテーション"

Copied!
56
0
0

読み込み中.... (全文を見る)

全文

(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)

参照

関連したドキュメント

目指す資格 推奨 Microsoft 社の Access を用い、データベースの設計・完成までを目標 授業概要.. とする。

表-1 研究視点 1.景観素材・資源の管理利用 2.自然景観への影響把握 3.景観保護の意味を明示 4.歴史的景観の保存

可視化や, MUSIC 法などを用いた有限距離での高周 波波源位置推定も試みられている [5] 〜 [9] .一方,

テキストマイニング は,大量の構 造化されていないテキスト情報を様々な観点から

テストが成功しなかった場合、ダイアログボックスが表示され、 Alienware Command Center の推奨設定を確認するように求め

「特定温室効果ガス年度排出量等(特定ガス・基準量)」 省エネ診断、ISO14001 審査、CDM CDM有効化審査などの業務を 有効化審査などの業務を

目標 目標/ 目標 目標 / / /指標( 指標( 指標(KPI 指標( KPI KPI KPI)、実施スケジュール )、実施スケジュール )、実施スケジュール )、実施スケジュールの の の の設定