【レポート】サーバーレスのエンタープライズへの拡大とベストプラクティス #AWSSummit

【レポート】サーバーレスのエンタープライズへの拡大とベストプラクティス #AWSSummit

Clock Icon2019.06.13

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

こんにちは、岩城です。

2019年6月12日(水)〜2019年6月14日(金)の 3 日間にわたり、 千葉県の幕張メッセにて AWS Summit Tokyo 2019 が開催されています。

こちらで講演されたセッション「サーバーレスのエンタープライズへの拡大とベストプラクティス」を聴講しましたのでレポートします。

概要

セキュリティやガバナンスからパフォーマンス、モニタリング、ロギングに至るまで、どのアプリケーションであっても新しく構築する際には多くの考慮点があります。これらはサーバーレスアプリケーション構築の際にはどうでしょう? どのようにすることがうまくいく秘訣なのでしょう? そして開発者が迅速にサーバーレス思考へと移るためのベストプラクティスは? 本セッションでは、サーバーレスアプリケーションに対するこうした要因に触れ、そこでサーバーレスがもたらす利点を説明します。また、それぞれの組織においてサーバーレスアプリケーションの構築を円滑にするベストプラクティスとパターンについて、グローバル視点でのサーバーレス動向を含めてご紹介します。

スピーカー

  • アマゾン ウェブ サービス ジャパン株式会社 Principal Developer Advocate
  • Chris Munns

※敬称略

レポート

サーバーレスとは?

  • インフラのプロビジョニングやインフラの管理不要
  • 自動的にスケールする
  • 価値に対して支払う
  • 使っていなければ払わない、あくまでアプリの価値に対して支払う
  • 高可用性
  • セキュア

サーバーレスによって

  • アジリティの向上
  • 運用工数の軽減
  • 市場投入の迅速化

Lambda

  • サーバーレスアプリケーション
  • イベントソース→ファンクション→サービス
  • イベントソース
  • データ状態の変更
  • エンドポイントへのリクエスト
  • リソース状態の変更
  • ファンクション
  • 様々な言語に対応
  • AWSが管理している言語
  • ランタイムAPIを介して好きな言語を使える
  • サービス
  • AWSのサービス
  • AWS外のサービス

典型的なユースケース

  • Webアプリ
  • 静的なWebアプリ
  • 複雑なWebアプリ
  • バックエンド
  • データ処理
  • リアルタイム
  • バッチ
  • チャットボット
  • Amazon Alexa
  • カスタムスキルにLambdaを使える
  • ホスティングするスキルとしてLambdaが一番と言われている
  • ITオートメーション

よくある懸念事項

  • 開発メンバーをどうやって育てるか
  • 正しいレベルのガバナンスをどのようにして設定するか
  • どのようなセキュリティコントロールができるか
  • なにをどの様にロギング/モニタリングすべきか
  • パフォーマンスをどのように計測するか

ファストデベロップメントの実現

  • DevOps
  • 3つのポイント
  • アプリケーションとインフラの定義をコードで実施
  • 都度アプリケーションとインフラをテスト
  • ビルド、テスト、デプロイ、プロセスを自動化

AWS SAM

  • サーバーレスに最適化されたCloud Formation拡張
  • 特別なサーバーレスリソースタイプ
  • ファンクション、API、テーブル、レイヤ、アプリ
  • Cloud Formationでサポートされているものはすべて利用可能
  • オープンな仕様

SAMテンプレート

  • 20行でで以下を作成可能
  • Lambdaファンクション
  • IAMロール
  • APIGateway
  • DynamoDBテーブル
  • これをCloud Formationであれば恐らく100行掛かる

SAMテンプレートの機能

  • 非SAM Cloud Formationを同じテンプレートに包含可能
  • pararmeters、mappings、outputsなどをサポート
  • 組み込み関数
  • importvalueをサポート
  • yamlまたはjsonをサポート

AWS SAM CLI

  • CLIツール
  • サーバーレスアプリのローカル開発、デバッグ、テスト、デプロイ、モニタリング可能

その他のローカル開発ツール

  • Step Functions Local
  • DynamoDB Local
  • LocalStack
  • Atlassianのチームが開発
  • 22のAWSサービスに対応

CI/CDツールに関して

  • 使いたいCI/CDツールを利用できる
  • Serverless Framework、Zappa、Apex、Beginを用いたデプロイ
  • 現在利用している各種ツールも利用できる

サーバーレスのデプロイ

  • テンプレート→パッケージ→デプロイ→テストスタック→デプロイ→本番用スタック
  • テストスタック完了後にフィードバックループ
  • 本番用スタック完了後にフィードバックループ

セキュリティとガバナンス

  • パーミッション
  • ファンクションポリシー
  • バケットXでの操作はLambdaファンクションZを呼び出し可能
  • クロスアカウントアクセス
  • 同期/非同期呼び出しのケースで使用
  • 実行ロール
  • DynamoDBのテーブル読み込み可能
  • ファンクションがアクセス可能なAWSリソースAPIに制限

SAMポリシーテンプレート

  • 50を超える事前定義ポリシー
  • 主だったユースケースを網羅している
  • 今後も追加する予定

サーバーレスにおけるガバナンス

  • このファンクションプロパティはタグ付けされているか
  • どのようにタグ付けされているVPCにファンクションがあるのが正しいのか
  • 実行ロールは組織ポリシーに準拠しているか
  • 最新のLambdaレイヤーを使っているか
  • リソースを変更した人と変更理由を特定・追跡できるか
  • ファンクションの起動はどこから何によって?

AWS CloudTrailとAWS Configを追加すればOK

  • AWS CloudTrail
  • 自動的なイベントログの記録と集中管理を通してアカウントにおける操作の準拠と監査を執行
  • APIイベントを監視することでセキュリティ監査およびオペレーションのトラブルシューティングに貢献
  • カスタムワークフローを使っているAPIの特定
  • AWS Config
  • 継続的な記録アセスメントサービス
  • AWSリソースに対する構成変更を追跡
  • 構成がポリシーに準拠していないければラートを通知
  • 非準拠のリソースの自動的な修復機能も提供

コードに対するガバナンス

  • デリバリーパイプライン内でのコードチェックの強制執行
  • 3rdパーティソフトの更新やライセンス競合の検査
  • 可能なら保管されたアーティファクトから3rdパーティソフト利用を制御
  • Lambdaレイヤーの利用

Lambdaレイヤー

  • 昨年のre:Inventで発表
  • ファンクションから簡単にコードを共有利用

ガバナンス観点でのLambdaレイヤー

  • 変更不可、アップデートする時は新しいバージョンが作成される
  • 不要になったものを削除することができる
  • 特定バージョンの削除または利用権限の剥奪が行われた場合、それに依存していたファンクションは引き続き機能するが新しいファンクションでは機能しない

モニタリング・ロギング・トラブルシューティング

  • CloudWatchとX-Ray
  • CloudWatch
  • クラウドのリソースとアプリケーションの完全な透明性
  • 組み込み済みのメトリクスとロギング
  • 7つのビルトインメトリクス:Lambda
  • 起動回数、起動時間、エラー、スロットルされた呼び出しなど
  • 7つのビルトインメトリクス:APIGateway
  • CloudWatch Logs
  • APIGatewayロギング
  • Lambdaロギング
  • ログピボット
  • Amazon ElastiCacheまたはS3へのエクスポート
  • X-Ray
  • サーバーレスアプリケーションのプロファイリングとトラブルシューティング
  • Lambda:サポートするすべての言語に対するリクエストの記録・計測、コードからの呼び出しをキャプチャ
  • APIコールやDBへのコールなど
  • APIGateway:HTTPコールに追跡ヘッダを追加しX-Rayへデータをレポート
  • ウォーターフォールですべてのファンクションのコールを確認できる
  • アナリティクス
  • デバッグをしてパフォーマンスの異常を特定して改善できる

ファンクションのための計算パワーの微調整

  • Lambdaではメモリ設定だけが表に見えるがCPUコアとメモリ容量の割合は比例して割り当てられる
  • より大きなメモリを選択する方が良い

より賢いリソース割り当て

  • ロジックに適合したリソース割り当て(3GBまで!)を利用すべし
  • 例えコストが少し上がっても実行時間が10秒早くなるのであれば、メモリを上げた方が良いこともある
  • X-Rayを使ってファンクションがどれだけのメモリをコンフィグレーションするのか確認する

何が悪いかを検出するために

  • X-Rayをonにする
  • Lambdaロギングの効力をあなどるな
  • 最も意味あるメトリクスはビジネスロジックと密接
  • 事例
  • 非常に沢山の情報をKinesis Streamに入れ、Lambdaファンクションから別のAPIを呼び出していた
  • Lambdaファンクションがタイムアウトした
  • 下流のAPIが時間を食いすぎて問題になっていた
  • Kinesis Streamをスケールアップすると解決することが分かった

まとめ

FIN,ACK 最後の確認

  • アプリケーションの構築デプロイ管理のためのツールを活用せよ
  • CI/CDと一般的なDevOpsのベストプラクティスは有用
  • ガバナンスにはAWS TrailとAWS Configが効果的
  • Lambdaレイヤーは依存性ライブラリや3rdパーティコードの標準化に有効
  • CloudWatch Logsやメトリクスは組み込み済み
  • X-Rayはパフォーマンスにおける深い情報と洞察を提供

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.