【レポート】AWS Summit Tokyo 2017:Running Container-Enabled Microservices on AWS Bootcamp #AWSSummit

【レポート】AWS Summit Tokyo 2017:Running Container-Enabled Microservices on AWS Bootcamp #AWSSummit

Clock Icon2017.06.16

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

コンニチハ、千葉です。

AWS Summit Tokyo 2017 の 「Running Container-Enabled Microservices on AWS Bootcamp」を受講してきました。 このブートキャンプは、コンテナやマイクロサービスの概要から、ECSを利用したスケールアウト、デリバリパイプラインに関するハンズオンが含まれます。

Running Container-Enabled Microservices on AWSは、現在英語圏では開催されているようです。

aws-summit-tokyo-2017-day3-microservice-1

講師

上原 誠さん

aws-summit-tokyo-2017-day3-microservice-2

松本 雅博さん

aws-summit-tokyo-2017-day3-microservic-3

内容

「Running Container-Enabled Microservices on AWS」は、コンテナ対応のアプリケーションの管理およびスケーリングについて詳細かつ実践に説明する、エキスパートレベルのトレーニングブートキャンプです。

このブートキャンプでは、コンテナおよびマイクロサービスアーキテクチャの概要について説明します。ここでは、マイクロサービスのベストプラクティスに 従って、サンプルのアプリケーションをコンテナ化して設定する方法について学習します。また、AWS のコンテナ向けサービスを対象としたハンズオンラボでは、長期に渡り実行するアプリケーションやサービスのスケジュール設定、マイクロサービスアプリケー ションに対するソフトウェアデリバリーパイプラインのセットアップ、および顧客の負荷をベースとしたアプリケーションの伸縮自在なスケーリングの実装する 方法などを演習します。

引用元

対象者

  • 開発者
  • システム運用管理者
  • ソリューションアーキテクト

前提条件

  • AWS のコアサービスおよび機能についての基本的な知識
  • Docker についての基本的な知識

アジェンダ

  • AWSのマイクロサービスの概要
  • コンテナベースのマイクロサービスの継続的デリバリ(継続的インテグレーション/デリバリーパイプライン)
  • ECSでコンテナ対応のマイクロサービスを実行する(可用性とスケール)

セッションの様子

参加者は18名で、既にDockerやECSを触られている方が多い印象でした。座学では、体系的にマイクロサービスに必要な設計ポイント、またアーキテクチャを学ぶことができました。 ハンズオンでは、モノリシックアプリをマイクロサービス化、ECSの構築からAutoScalingの設定までを行いました。ハンズオンの内容が濃く、幅広く学ぶことができました。

受講内容

AWSのマイクロサービスの概要

  • モノリスとは?データアクセス、ビジネスロジック、表示など1つのプロセス上で全て実行している状態
    • 問題:コード変更維持、影響範囲が大きい、テストが難しい、製品化までのリリースに時間がかかる、スケールするときはアプリ全体をスケールするしかない
  • マイクロサービスとは?
    • 要素(機能・コンポーネント)を疎結合にする(ネットワーク経由でのコンポーネント間アクセス)
    • コンテキスト境界をもうける:サービスアップデートしても他のサービスに影響しない
    • 俊敏性を手に入れられる
  • マイクロサービスの構造
    • APIで連携
    • 疎結合でソフトウェア間で依存しないようにする
  • マイクロサービスの原則
    • マイクロサービス間で通信する場合は、お互いパブリックAPIのみ使用する(バージョンアップ時は互換性を気にする)
    • ジョブに適したツールを使う、開発者に自由を与えるように欲しいコンポーネントは選べる(例:DynamoDB、ES、好きな言語を選ぶ等)
    • サービスを保護する、API Gatewayを利用するとセキュリティ、スロットリング、認証等保護できる
    • エコシステムにおける良い住人になる:SALの設定や可用性、拡張性を確保する
    • 単なる技術変革以上のものを達成する:コンポーネントを単一のチームが開発・デプロイ、保守し責任を負う
    • すべてを自動化する(ビルド、テスト、リリース)※ただし、一気に全部やろうとしない、デプロイ自動化だけやるのもあり

Dockerについて

  • コンテナとは
    • Linuxカーネル機能であるnamespaceを利用し、プロセス、ファイルシステム等を分離する
    • Linuxカーネル機能であるcgroupを利用し、リソース(CPUやメモリ)を制御する
    • VMとの大きな違いは、ハイパーバイザーが存在しないのこと、なのでコンテナの起動は速い
  • コンテナの設計思想
    • 1コンテナ、1プロセス
    • プログラミン言語は自由
    • イミュータブルな構成になる
    • 1コンテナは、1つのバージョン、1つのアーティファクトをパッケージする
  • Dockerのメリット
    • コンテナを瞬時に起動できる
    • 同じイメージをどこでも起動できる(ポータビリティ性)
    • コンテナ単位で柔軟にスケールできる

演習

  • 演習の流れ:モノリスなアプリをマイクロサービス化していく
  • 写真をアップロードしたら髭をつけるアプリ(モノリシック)をECSへデプロイ
  • マイクロサービスに分割して、3つのコンテナをデプロイ
  1. Dockerfileを利用しモノリシックアプリを起動
  2. Docker Composeを利用し、マイクロサービス化したアプリを起動
  3. ECS上でマイクロサービス化したコンテナを起動

コンテナベースのマイクロサービスの継続的デリバリ(継続的インテグレーション/デリバリーパイプライン)

  • ソフトウェアはスピードが重要
  • リリースするまでのプロセス:ソース > ビルド > テスト > デプロイ
  • チームを分ける:2つのピザが食べ切れるくらいの人数
  • デリバリーも、チーム単位で実施する(他チームに依存してしまうと、スピードが出せない)
  • AWS CodePipline:ビルド、テスト、デプロイをワークフローで定義、実行するサービス

演習

  • CodePiplineを使ってビルド、デプロイを自動化
    • コード管理:CodeCommit
    • ビルド:Jenkins
    • デプロイ:CloudFormation(ECSへデプロイ)
    • テスト:Jenkins + Postman
    • フロー:CodePipline

ECSでコンテナ対応のマイクロサービスを実行する(可用性とスケール)

  • ECS
    • サービスで必要な数のタスクを維持
    • サービスの負荷分散
    • 柔軟なデプロイ
    • マルチAZになるように起動する
  • ECSのスケジューラは2種類ある、バッチ向けと長時間実行するアプリ(Webサービス等)向け
  • ECSでのスケジューリング※バッチ向け
    • タスクを1度だけ実行する
    • バッチジョブ向け
  • ECSでのスケジューリング※長時間実行アプリケーション(Webサービスなど)
    • ヘルス管理(起動するコンテナ数を指定できる)
    • スケールアウト、スケールイン
    • 複数AZになるように配置
    • コンテナのグループ化
    • ロードバランサーへの自動登録
  • モニタリング
    • CloudWatchのメトリクス
    • CPUReservation
    • MemoryReservation
    • CPUUtilization
    • MemoryUtilization
    • サードパーティを利用(Datadog、NewRelic、Sysdig Cloud等)
  • ECSクラスタのスケール
    • AutoScaling利用でスケーラビリティを得る
    • スポットフリート利用でコスト効率最大化
  • コンテナのスケール
    • 起動するコンテナ数を指定する
    • ダイナミックポートを利用する
    • サービスのAutoScalingを利用する

演習

  • コンテナのAuto Scalingの設定
  • サービスを遮断し自動復旧の確認
  • DockerコンテナのAutoScaling
  • ECSクラスのAutoScaling

受講したメンバーの感想

藤本

お客様先に行った時にコンテナ、Docker に関して質問されることがあり、ノウハウを得られればと思い参加しました。私は検証でたまにローカル端末上で Docker を触るぐらいで、ECS はほとんど経験ありませんでした。 本トレーニングではマイクロサービス -> Docker -> ECS -> 運用を意識した ECS の活用と順序立てて進められていくことで体系的に学習することができ、今までマイクロサービス、Docker のふわっとした必要性を改めて理解できました。また各章で座学による解説、それを体験するハンズオンを実施することでより理解が深まりました。 5時間という短い時間だったため、完全に飲み込めていないところも後日資料を配布いただけるとのことなので、改めて復習して、検証して、ECS をお客様に提案できるようになりたいです。

望月

DockerやDockerを利用したMicroserviceの思想について整理して学ぶことができた、良い研修だったと思います。ECSをdocker-composeと同じ感覚で扱うためのecs-cliや、CI/CDをAWS上でECSと連携させて動作させる方法をハンズオンを含めながら非常にわかりやすく学ぶことが出来たと思います。触れた内容は基礎的な部分でしたが、ベースとして非常に重要な知識を学べるブートキャンプだったと思っています。引き続きECS上での開発・運用にチャレンジし、得た知見をブログなどで広めていきたいと思います。

千葉

マイクロサービスはなんぞや?からECSのアーキテクチャ、ECSを利用したCI/CDから自動スケールまで実践を交えて学べました。 ハンズオンがあることにより、具体的なオペレーションレベルまで把握することができました。特にECSでのコンテナデプロイ方式、AutoScalingの設定方法がわかり、座学も大切ですがハンズオンも重要だと思いました。個人的にはビルドプロセスはJenkinsだったので、CodeBuildで試してみたいなと思いました。

まとめ

かなり内容が濃いブートキャンプでした。ECSを利用したマイクロサービス化を検討している方にぴったりな内容だと思います。 前提条件にもありますが、ブートキャンプ受講する前にDockerの知識をある程度つけておくと講義の理解が早いと思います。ローカルで起動して試したり、少しでも仕組みを理解しておくとブートキャンプが濃いものになるかなと思いました。私も、どんどんDocker、ECSを利用していきたいと思います!!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.