More than 5 years have passed since last update.

[セミナー] 2019/07/01_AWS Summit Tokyo re:Cap Day1 サーバーレス & コンテナ

Last updated at 2019-09-05Posted at 2019-09-05

こちらは2019/7/2にQiita:Teamに投稿した記事をリライトしたものです。

AWS Summit Tokyo re:Cap Day1 サーバーレス & コンテナ

AWS Summitのサーバーレスとコンテナに関するセッションの再演です。
\

めざせ！サーバーレスプロフェッショナル

サーバーレスとは
- サーバー管理が不要
- 柔軟なスケーリング
- アイドル時のリソース確保が不要
- 組み込まれた高可用性
開発・テスト・フレームワーク
- AWS Cloud9
- 各言語に対応したIDE
  - AWSツールキットを入れる
- サービスが増えていくと小さなリソースが増えていく
- AWS SUM
  - CoundFormationの拡張
  - AWSでサーバーレスアプリケーションを表現するスタンダードモデル
  - 関数・api・イベントソースとデータストア
  - サーバーレスアプリケーションのデプロイと管理を自動化
  - SUMテンプレートにてPackage & Deploy
  - ローカルでSUMテンプレートからCloudFormationテンプレートに変換、ソースコードはS3に配置する
  - awslabs
    - Awsがツール、サンプル、ライブラリなどを開発・後悔しているリポジトリ群
      - SUMテンプレートのサンプルなどがおいてある
- AWS SUM CLI （旧SUM Local）
  - https://aws.amazon.com/jp/blogs/news/aws-serverless-application-model-sam-command-line-interface-build-test-and-debug-serverless-apps-locally/
  - サーバーレスアプリケーションのためのローカルテストツール
  - ローカルマシンでレスポンスやログの確認
  - Lambdaの実行環境をシミュレートしたDockerイメージ
複数環境・CI/CD
- 開発・テスト・実行には複数環境が必要
  - なぜ？
    - リソースの重複利用を避けたい
    - ユーザーに影響を与えずに新しいコードをテストしたい
    - インフラの変更を安全にテストした
  - 方法は？
    - アカウント戦略：アカウントを分ける
      - 同じアカウントでスタックを分ける
        
        小規模チームや個人向け
        
        メリ
        
        リソース管理が簡単
        
        管理や監視ツールが見やすい
        
        デメ
        
        許可やアクセスの分離が難しい
      - アカウントを分ける
        
        大規模チームや企業向け
    - Lambda：環境変数
      - 関数を動的に渡すことができるキーと値のペア
      - オプションでKMS経由で暗号化できる
      - ステージごとに環境を作成するために利用すると便利
    - Lambda：バージョニング・エイリアス
    - API Gateway：ステージ
      - 環境変数のように利用できる
      - $contextオブジェクトで利用できる
  - 1つのテンプレートから複数の環境を構築
  - AWS Codeサービスと組み合わせてCI/CD
    - Source, Build, Test, Deploy, Mainter
    - CI/CDパイプラインの構成例
      - CodeStar
        
        テンプレートで簡単に構築
        
        テンプレートを検索
        
        Node.js, Web Service, AWS Lambda（サーバーレスで実行）を選択
        
        Cloud9も合わせて設定できる
    - AWS CodeDeploy
      - 段階的なデプロイメント
        
        Canaly X Percent Y Minutes
        
        Linear X PercentEvery Y Minutes
        
        AllAtOnce
      - アラーム
      - フック
        
        テストに使える
    - API Gateway
      - カナリアリリース
        
        新しいステージに進むトラフィックの割合を設定し、ステージの設定や変数をテストできる
        
        ロールバックするには、デプロイを削除するか、トラフィックの割合を0に設定する
        
        問題がなければカナリアリリースを本稼動に昇格させ、カナリアをデプロイから無効にする
        
        ABテストにも使える
    - AWS Serverless Application Repository
      - 再利用
        
        SUMやCloudFormationとして再利用する
        
        Serverless Application Repository経由で再利用する
監視・モニタリング
- CloudWatch
  - メトリックス
    - デフォルトメトリックス
    - カスタムメトリックス
  - ログ
- AWS X-Ray
  - 各ノードの呼び出しの結果を色で分類し、割合を円グラフに
    - グリーン：成功した呼び出し
    - レッド：5xx Errors
    - イエロー : 4xx Errors
    - パープル：429 Too Many Requests
  - 平均レイテンシ
  - トレース数
  - サービス名
  - サービスの分類
デザインパターン
- API、モバイル関連
  - 動的Webアプリ、モバイルバックエンド
    - Api Gateway -> Lambda -> DynamoDB
  - インタラクティブAPI、データ配信API
    - Api Gateway -> Lambda ->WebSocket
- データ加工
  - 画像処理、シンプルなデータ加工
    - S3 -> Lambda
- データイベント処理
  - 流入データの連続処理
    - Kinesis -> Lambda -> S3
- バックエンドデータ処理
  - スケジュール・ジョブ/CRON
    - CloudWatrch -> Lambda

Kubernetes on AWS（Amazon EKS実践入門）

コンテナとは
- ソフトウェアをOS内の独立した環境で実行する技術
- 代表的な実装：Docker
  - Build share and run any application, anywhere
  - 依存関係をパッケージング
    - どこでも動くポータビリティ
    - いつでも作れていつでも捨てられる
- Build/Share/Run
  - Build
    - Dockerfile
      - docker build -t REPO/TAG
  - Share
    - DockerHub（イメージレジストリ）
      - docker push REPO/TAG
  - Run
    - コンテナホスト
      - docker run .. REPO/TAG
- コンテナのユースケース
  - マイクロサービスのアプリケーション
  - ジョブ実行
  - CI/CDの実行
  - 機械学習
- コンテナ実行（RUN）時の課題
  - 耐障害性
    - コンテナのホストが停止したらコンテナ全滅、機能停止
  - 運用性
    - コンテナはどのホストで動かす？リソースは空いてる？
    - 通信したいコンテナはどこにいる？
  - スケール
    - 負荷に応じてコンテナをスケールしたい
Kubernates
- オープンソースのコンテナオーケストレーションツール
  - Cloud Native Computing Foundationが開発プロジェクトをホスト
- 人気の理由
  - 成長を続けるユーザー数とコミュニティ
  - Runs Anywhere（クラウドでもオンプレでも）
  - 拡張可能なAPIとエコシステム
- Kubernatesが提供する機能
  - ノードにコンテナを自動配置
  - 失敗したコンテナの自動復旧
  - 手動スケール・オートスケール
  - 通信相手を特定・ロードバランス
- Kubernatesのインフラ構成
  - コントロールプレーン
    - コンテナの管理をする場所
      - どこでコンテナを動かす？生死は？いつ止める？
      - デプロイ時にどういう風に配置する？
  - データプレーン
    - 実際にコンテナが稼働する場所
      - コントロールプレーンからの指示に従って起動
      - 各種状態をコントロールプレーンにフィードバック
- Kubernatesオブジェクト
  - Pod
    - デプロイの最小単位「1つ以上のコンテナ」から構成
    - Pod内コンテナはIPアドレス・ストレージなどを共有
  - Service
    - Podを名前解決により発見（サービスディスカバリー）
    - ロードバランス
  - Deployment
    - Podを維持、コントロールするReplicasetの管理（指定Pod数の管理）
- Kubernatesマニフェストと宣言的設定
  - マニフェスト - あるべき状態を宣言
EKS
- Kubernates運用の悩み
  - Kubernatesコントロールプレーンの運用は重労働
  - 運用中のKubernatesバージョンアップは大変
    - 3ヶ月に1回最新バージョン、サポートは過去3バージョン分のみ
  - もっとアプリケーションを実行する部分に集中したい
- EKS
  - Kubernatesコントロールプレーンをマネージドで提供
  - Kubernatesリリースを改変なく利用
- 使う理由
  - 堅牢なコントロールプレーンをマネージドで提供
    - コントロールプレーンの運用からの解放
  - Kubernatesの運用を支援する機能
    - バージョナップ、コントロールプレーンログの集約
  - AWSマネージドサービスとスムーズな連携が可能
  - 選択可能なデータプレーン（ノード）
ラーニングパス
- Black Belt オンラインセミナー

サービスメッシュは本当に必要なのか、何を解決するのか

“Monolith”という呼称に込められるニュアンス
- 関係者間調整のオーバーヘッド
- 変更による影響範囲の広さ
- モジュール構造維持の難しさ
- 非効率なスケーリング
- テスト・ビルドに要する時間の長さ
マイクロサービス化に期待される効果
- 変更による影響範囲の局所化
- モジュール境界の維持しやすさ
- 独立したデプロイとスケーリング
- 自律的なチームによる開発・運用
- Polyglot(-able)「多言語による開発（ができる）」
モノリスの考察
マイクロサービス
- マイクロサービスの課題
  - サービスの適切な分離
    - 手法はあるが、正解はない
  - テストの難しさ
    - 依存するサービス、依存するサービスに依存するサービス、、、
  - 影響範囲を自サービス内に収める難しさ
    - APIの後方互換性を壊せない、ダウンタイムを作れない
  - サービス間通信の信頼性 ( Reliability )
    - マイクロサービスは一種の分散システム
    - ネットワーク経由通信 = 失敗が前提
    - 一時的なネットワーク状況による失敗
    - 対向サービスの不具合・停止による失敗
    - 防御的実装の必要性
      - 呼び出し先サービスの位置は一定ではない
        
        サービスディスカバリ
      - 一時的な呼び出しの失敗
        
        リトライ
      - 継続した呼び出しの失敗
        
        サーキットブレイカー
      - 呼び出し先サービスのパフォーマンス悪化
        
        タイムアウト
      - 呼び出し”元”システムの不具合
        
        スロットリング
  - サービス間通信の可観測性 ( Observability )
    - マイクロサービス軍 = 1つのシステム
    - 外形的には「システム」の失敗
    - 失敗は、どこで、なぜ起きたのか
    - システムを観測できる実装の必要性
      - ログ・メトリクス・トレース情報出力
      - 各サービスの既存実装の出力フォーマットが不揃いだとコンテキストが見えない
      - 「システム」全体の観測には不向き
      - システム全サービスで統一したログフォーマットを実装
        
        全てを実装しきることは可能なのか
        
        各サービスへの個別実装
        
        複数の言語やフレームワーク
        
        実装担当者と品質担保方法
        
        統一フォーマットの変更
        
        一貫性ある実現方法が必要
        
        共通ライブラリという解決策
        
        アプリケーションコード側に改修が必要
        
        共通ライブラリの変更時のコスト
        
        一貫した実装「共通ライブラリ」が密結合が生まれてしまう
        
        プロキシのオフロードというアイデア
        
        ->サービスメッシュ
サービスメッシュ
- Envoy
  - OSS
  - コミュニティサポートと多くのインテグレーション
  - 設定
    - ymlに記載
- サービスメッシュとアプリケーションの密結合
  - 本質的にネットワークとポロしの定義やトラフィックコントロールポリシーはアプリケーションが知る必要のない話
  - さまざまな問題点
- AWS App Mesh
  - サービスメッシュのコントロールプレーン
    - メッシュは全体構造の定義
    - メッシュを構成するプロキシに対し動的に設定を配信
  - アプリケーションレベルのネットワーク
    - ログ・メトリクス・トレース情報の容易な出力
    - クライアントサイドのトラフィックルーティングポリシー
  - クラスタやサービスにまたがるメッシュの構築
  - マネージドコントロールプレーン
  - トラフィックコントロール
サービスメッシュは本当に必要なのか？
- あなたのシステムにとってサービスメッシュは必要か？
  - サービスメッシュ
    - サービス間通信の信頼性と可観測性を確保する一貫性ある手段の１つ
  - AWS App Mesh
- 課題に対する必要性を検討する
  - そもそもサービスメッシュは必要か
    - X-Rayでの分散トレーシング、ALBでのトラフィックコントロール
    - OSSライブラリの利用で十分低コストなケース
  - 動的なサービスメッシュが必要か
    - Envoyに静的設定ファイルを利用する

感想など

サーバーレスの開発手法や本番運用の話を聞いてみたいと思っていたのでとてもためになりました
AWS Loft Tokyoがとてもきれいで広かったのでリモートワークするにはもってこいな環境だなと

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up