[レポート]モノリスからマイクロサービスへ  〜そしてそこに至るまでの道のり〜  #reinvent #CON360

[レポート]モノリスからマイクロサービスへ 〜そしてそこに至るまでの道のり〜 #reinvent #CON360

Clock Icon2018.11.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事はre:Invent 2018のセッション「CON360 - From Monolith to Microservices (And All the Bumps along the Way)」のレポートです。

概要

Applications built on a microservices-based architecture and packaged as containers bring several benefits to your organization. In this session, Duolingo, a popular language-learning platform and an Amazon ECS customer, describes its journey from a monolith to a microservices architecture. We highlight the hurdles you may encounter, discuss how to plan your migration to microservices, and explain how you can use Amazon ECS to manage this journey.

スピーカー

  • Brent Langston - Sr Developer Advocate, AWS
  • Max Blaze - Staff Operations Engineer, Duolingo

レポート

前半 - モノリスからマイクロサービスへ移行するときのハードル

前半はBrent Langston氏がモノリシックなアーキテクチャ(モノリス)からマイクロサービスへと変わっていく、その過程で遭遇した出来事を紹介。

モノリスからマイクロサービスへ移り変わるときは技術だけでなく、人やワークフローも変わる必要がある。

People -> Workflow -> Technical -> People -> ...

人 - 準備のためのハードルは何か

新しいやり方とは対照的な古いやり方

  • ローカルでどうやって開発する?
  • デプロイがつらいけど、どうなる?

このハードルに対してAWSがどう助けるのか

  • AWS Cloud9
  • AWS CodeBuild
  • AWS CodePipeline
  • AWS ECS
  • AWS EKS
  • AWS Fargate

ワークフロー - Dockerはどう移行を助けるのか

  • パッケージング
  • ディストリビューション
  • スケールアップ、スケールダウン
  • 実験を簡単にする

このハードルに対してAWSがどう助けるのか

  • Amazon ECR
  • Amazon ECS
  • Amazon EKS
  • AWS Fargate
  • AWS CloudFormation
  • Application Load Balancer
  • Amazon CloudWatch
  • AWS CodePipeline
  • AWS CodeBuild

技術 - オーケストレーションがどんな問題を解決するのか?

  • プロセスモニタリング
  • トラフィック
  • サービスディスカバリ
  • スケールアップ・ダウン
  • デプロイ
  • イミュータブルインフラ
  • コスト削減

このハードルに対してAWSがどう助けるのか

  • Amazon EKS
  • AWS Fargate
  • AWS CloudFormation
  • AWS Auto Scaling
  • Application Load Balancer
  • Amazon CloudWatch
  • Amazon Route 53

後半 - Duolingoのモノリスからマイクロサービスへの移行事例

後半はMax Blaze氏から無料語学学習アプリDuolingoのモノリスからマイクロサービスへの移行事例の紹介。

Duolingoのサービスは2013年のローンチから2018年まで、この図のようにサービスの構成が変化してきた。

なぜマイクロサービスに移ったのか?

  • スケーラビリティ
  • ベロシティ
  • 柔軟性
  • 信頼性
  • コスト削減

どうはじめにマイクロサービス化する対象を決めたのか?

  • 小さいけど、インパクトの大きい機能
  • サイズ、複雑さ、リスクが増す
  • 依存関係を考慮

モノリスとマイクロサービスの可用性

  • モノリス: 0.99
  • 連結されたマイクロサービス: 0.99 * 0.99 * 0.99 = 0.97
  • 独立したマイクロサービス: 1 - (1 - 0.99)の3乗 = 0.999999

なぜDockerを使うのか?

  • ビルドプロセスの標準化と依存関係のカプセル化
  • ローカル開発環境と同様のプロダクション環境
  • 素早いデプロイとロールバック
  • 柔軟なリソース割当

なぜAmazon ECSでDockerを使うのか?

  • タスクのオートスケーリング
  • Amazon CloudWatch Metrics
  • タスクレベルのIAM
  • 動的なALBターゲット変更
  • 管理しやすさ

アーキテクチャとCI/CD

マイクロサービス化したことによる結果

  • スケーラビリティ: 100以上のマイクロサービス
  • ベロシティ: 各サービスチームがモジュールをデプロイ
  • 柔軟性: 公式に3つのプログラミング言語をサポート
  • 信頼性: 99.99%の可用性を前クォーターに記録
  • コスト: 計算資源のコストを60%削減

さいごに

モノリスからマイクロサービスへと移り変わるときは技術面だけではなく、ワークフローやチームの面でも変化が必要になります。
その変化の際には、様々なハードルがありますが、人とワークフロー、技術の面の多くをAWSのサービスがサポートしてくれます。

オンプレミス環境で苦労していたあの日々は何だったのだろう...。
開発者にとって良い時代が訪れましたね。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.