1日1%成長する ~Aws Lambda Part2~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Aws Amazon CloudWatch CloudWatch Alarms CloudWatch Metricsをモニタリングしてアラームを発行可能 - OK - 正常:定義されたしきい値を下回っている - ALARM - 異常値:定義されたしきい値を上回っている - INSUFFICIENT_DATA - 判定不能:データ不足など データ欠落時の処理 - missing:欠落データポイントを考慮しない - notBreaching:欠落データポイントはしきい値内として処理 - breaching:欠落データポイントはしきい値釣果として処理 - ignore:現在のアラーム状態を維持
1日1%成長する ~Amazon CloudWatch~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Amazon CloudWatch 1ヶ月で800兆を超えるメトリクスの監視 2兆を超えるイベントトリガー 50ペタバイトを超えるログの収集 AWS Management Toolsの1つ -> Monitoring 機能 - Metircs - メトリクスに応じたアクションなど - Logs - ログの可視化 - Dashboards - 1つで確認 CloudWatch Metrics メトリクス - CloudWatchに発行された時系列のデータポイント - データポイントはタイムスタンプと測定単位を保持 - メトリクスは作成されたリージョンのみ 名前空間 - CloudWatchメトリクスのコンテナ - 異なる名前空間のメトリクスは相互に切り離されている - AWSサービスではAWS/が使用される ディメンション - メトリクスを一意に識別する名前/値のペア メトリクス生成 - 基本は1分、カスタムメトリクスの高解像度を利用して最短1秒 - EC2では基本モニタリングで5分、詳細モニタリングで1分 メトリクスデータの使用期間 - 1分未満:3時間、1分:15日、5分:63日 - 1時間のデータポイントだと15ヶ月(1年前のイベントと比較できる) Metric Math - METRICS関数、基本的な算術関数をはじめとした関数をサポート スナップショットグラフ - GetMetricWidgetImageAPIによりグラフのPNG画像を取得可能 CloudWatch Metrics カスタムメトリクス AWS CLIの"put-metric-data"もしくは"PutMetricData"APIでデータを登録 詳細度が1秒のデータを含む高解像度なメトリクスを発行可能 - APIコール時のスロットリング対策(上限緩和申請も検討) - 単一のput-metric-dataに複数のデータポイントを入れる - StaticSetを利用 - リトライ処理 エージェント 今まではCloudWatch Logsエージェント - EC2インスタンスのログデータを発行 統合CloudWatchエージェント(現在推奨) - メトリクスとログの両方を単一のエージェントで収集 - クラウドでもオンプレでも利用可能 - Linux,Windowsの両方で稼働 統合CloudWatchエージェント - JSON形式 - agent、metrics、logsの3つのセクション
1日1%成長する ~Amazon VPC Advanced 2~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Amazon VPC Advanced Transit GateWay ユースケース - 複数のVPCを使用しているお客様 - 多数のVPCにまたがるアプリケーションを構築するお客様 - ネットワークサービスの共有が可能 - DNS、IDS/IPS、Firewall - 管理のオーバーヘッドを削減 デジタルセキュリティと脅威インテリジェンス - 共有のVPCホストセキュリティツール - Firewall as a service - トラフィックを一回VPCをBITW(Bump In The Wire)と中でスィールする ミドルボックスみたいな箱を用意してそこで監査や侵入検知をする - Webアプリケーションファイアーウォール(WAF)、データ損失防止(DLP) 侵入検知/保護(IDS/IPS) - ネイティブAWSサービスでスケールアウト Transit GatewayとPrivateGateとの使い分け AWS PrivateLink - 1対多のコネクティビティ - IPアドレス重複サポート - ELB使用 - ELBと1時間あたりのエンドポイントコスト VPC間に相互信頼をもたない => お客様に開放とか AWS Transit Gateway - 多対多、1対多でルーティング - 1時間あたりのAZエンドポイント VPC単位の信頼、集中管理 Transit GatewayとVPN - TGWによるVPNの統合 - VGW同様トンネルあたり1.25gbpsの帯域を使用 ※BGPマルチパスによるEqual Cost MultiPath (ECMP)のサポート MAX50gbpsの帯域までテスト済
1日1%成長する ~Amazon VPC Advanced~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Amazon VPC Advanced VPC(Virtual Private Cloud) 【VPC Sharing = Shared VPC】 現状、マルチアカウントでの管理が多い? - 複数アカウントで最高レベルのリソースとセキュリティ分離を提供するため ※ほとんどの企業は複数のアカウントを構成したいと考えている 今まで、 dev,stage,productionなどで管理する際にdevとstageをつなぎたい場合などは vpc peeringを使うなどで対応していた。 - VPCの管理やVPC Peeringの管理も大変 - VPCの制限:Peering数が125 - VPC間のトラフィックコストが大きい VPC Sharingで解決する: 複数のVPCをまたいで設定が可能(グルーピングみたいな感じ) このグループ単位でNat Gatewayをくっつけられる ユースケース 1. VPC統合 より少なく、大きく、集中管理できる少ないVPC構成を実現。 相互接続を考慮しているアプリケーションに多くの利益 2. 既存ネットワークの置き換え - 大きくフラットなネットワークは小中規模の顧客で多く利用されている - 同一なフラットなネットワークをAWSで利用 - 複数アカウント利用時にも全てのメリットをAWSで VPC Shareingの利点 - IPアドレス資源の保護 - インターコネクティブ提供 - VPC peeringやTransit VPC不要 - ビリングとセキュリティ - 複数のアカウントを使用して分離のメリットを享受 - 職務分掌 - 集中管理するチームがVPCを作成管理 実際の動作 別々のアカウントで例えばAccountAでEC2、AccountBでRDSといったことが可能 共有Subnet内でそれぞれのアカウント権限によりインスタンスを起動できる VPC Sharingに向かない例 - 高い隔離が必要なケース(VPC分離で影響範囲を絞りたい場合) - 巨大で分散した組織 - 個々のチームで自分の環境の作成と管理を担当する組織 - VPC Sharingの制約 - VPCオーナーは別のアカウントで実行しているリソースを消せない - デフォルトVPC、サブネット、セキュリティグループのシェアは出来ない 【Transit GateWary】 従来の課題 - 従来の複雑なポイントtoポイントのVPCピアリングではスケールしない - VPN帯域の制約 - ルーティング構成の管理と設定時間の浪費 Transit Gateway(大きなルータみたいなもの) 1000以上のVPCとオンプレミス間の相互接続を簡単にする オンプレ or 他VPC => Transit Gatewary => AWS VPC 主要機能 - VPCとオンプレ間のルーティングポリシーを集中管理 - マルチアカウント間で1000を超えるVPC間接続をサポート - マルチVPNコネクションのスループット向上 - 柔軟なルーティングテーブルの分割とルーティングルール - スケーラブル - 運用の単純化 長所 - ネットワーク構成の単純化 - アカウント間、VPNやDirectConnectを集中管理 - Global Connectivity - リージョン間のピアリングが可能 - 管理を簡単にする ユースケース1:地理的に分散されたオンプレとVPCの相互接続 - 複数のVPCを使用している - 多数のVPCにまたがるアプリケーションを構築 - ネットワークの共有が可能 - 管理のオーバーヘッドを削減 ユースケース2:エッジの集約 - 全てのVPCで共通のVPNまたはDirectConnectGatewayを共有 - 複数のVPCにオンプレ接続時間を短縮
1日1%成長する ~Aws Lambda Part1~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Aws Lambda Part1 サーバレスとは? - インフラのプロビジョニング不要 - 自動でスケール - Lambdaはリクエスト数に応じて自動的に起動数がコントロールされる - - 価値に対する支払い - 高可用かつ安全 Lambda - ランタイム - 必要なときにコードを実行を行いたい - インフラの構成・管理が面倒 アプリケーションモデル イベントソース -> Lambda -> サービスなど イベントソース - S3にオブジェクトが作成される - Kinesisにストリームデータが保存される - HTTPSのリクエスト Lambda - PythonやNodejsなど サービス - S3やdynamodbなど Lambda関数 - AWS Lambdaで実行するアプリケーション - それぞれが隔離されたコンテナ内で実行される - 利用する言語の関数もしくはメソッドをハンドラーとして指定して関数を実行 - コードは依存関係も含めてビルド、パッケージングした上でアップロード 設定 - メモリ - 64MBごとに128MB~3008MB - 容量に応じてCPU能力も上がる - メモリ容量が一定数を超えるとコア数も増える - タイムアウト - 最大900秒(15分) - 実行ロール - 必要なAWSリソースへのアクセスを許可するIAMロールが必要 制限 - インバウンドネットワークはブロックされる - Listenとかはできない - アウトバウンドはTCP/IPとUDP/IP - ptraceシステムコールはブロックされる - TCP25番ポートはブロックされる イベントソース - ポーリングベース - ストリームベースとそれ以外 - Lambdaがポーリングをして処理するデータがある場合にLambda関数を実行 - それ以外 - Lambda関数はイベントソースから呼び出される - イベントソース - AWSのサービスorユーザが開発したアプリケーション 呼び出しタイプ 非同期 InvocationType:Event レスポンス:リクエストが受け付けられたかどうか 同期 InvocationType:RequestResponse レスポンス:返却される。レスポンス内容はLambda関数で用意 リトライ ストリームベースではないイベントソース 同期 - エラー発生時にレスポンスにFunctionErrorが含まれる - パーミッション、Limit、関数コードや設定による問題など特定のステータスコードが返却 - AWSサービスからの呼び出しの場合、その設定に従う 非同期 - 自動的に2回までリトライされ、その後イベントは破棄 - リトライ遅延有り - DLQ(Dead Letter Queue)を設定することでSQS or SNSトピックに移動させて確認可能 ポーリングベースでストリームベースのイベントソース - データの有効期限が切れるまでリトライ - 失敗したレコードの有効期限が切れるもしくは処理が成功するまで、そのシャードからの読み込みはブロックされ、 新しいレコードの読み込みは行われない - このLambdaの処理が完了(失敗含む)までブロックされてしまう ポーリングベースでストリームベースではないイベントソース - バッチのメッセージはすべてキューに返り、Visibility Timeoutがすぎればまた処理が行われる その後成功すればキューから削除される - 新しいメッセージの処理はブロックされない VPCアクセスの注意 - 設定するとインターネット不可 - グローバルIPは振られない - 十分なENIまたはサブネットIPがないとリクエスト数が増えたときに失敗する 同時実行数 - セーフガードとしてアカウントに対してデフォルトで1000で制限されている - 実績に応じて制限緩和申請 - 同時実行数を超えたリクエストはスロットリングエラー(429)が返却される - 非同期呼び出しの場合は15~30分程度はバーストとして許容されるがそれ移行はスロットリング対象 自動スケーリング - 初期値はリージョンごと異なる東京リージョンは1000(オレゴンとかは3000 - この値は制限緩和不可
1日1%成長する ~Aws Lambda Part2~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Aws Lambda Part2 エイリアスを利用したトラフィックの移行 routing-configを利用して2つのバージョン間でのリクエストトラフィックが 転送される割合(%)を決められる。 1. 2%のみ新しいバージョンへ 2. 残り98%は元のバージョンへ 3. 新しいバージョンが成熟 4. エイリアスを更新し、全てのトラフィックを新しいバージョンへ ※カナリアデプロイみたいな感じ Lambda Layers 様々なLambda functionで共通利用するコンポーネントを個別に持つのではなく、 Lambda Layerとして定義し参照することができるようにする /optの下に指定した順番に展開される - 特定のモジュールのバージョンを上書きされる - 同じパスや同名ファイルを使うときは注意 Layerは1つの関数で5個まで /optの下に各言語の依存を解決する固有パスがある - Python : python, python/lib/python3.7/site-packages - Nodejs : nodejs/node_modules, nodejs/node8/node_modules(NODE_PATH) デッドレターキュー(DLQ) 非同期実行時に2回のリトライにも関わらず処理が正常に終了しなかったときにそのイベントを指定された Amazon SQS or SNSのトピックへと送信 - イベントを失うことなく後続の処理で扱うことできるため、より信頼性が高いシステムが開発可能 - 関数単位で設定可能で全ての非同期で呼び出し可能 - 振り分け先 - SQS:SendMessage - SNS:Publish - 内容 - ペイロードには元のイベントのペイロードがそのまま格納される - ペイロード:パケットに含まれるヘッダやトレーラーなど付加情報を覗いたデータ本体のこと - メッセージ属性 - RequestID:一意のリクエストID - ErrorCode:3桁のHTTPエラーコード - ErrorMessage:エラーメッセージ(1KB) Custom Runtimes あらたのリリースされたRuntime APIで可能になった - Liunxで互換のランタイムを持ち込むことで、任意の言語でLambda関数を記述可能 - - Runtime bootstrap - ファンクションに"bootstrap"と呼ばれる実行ファイルを含める必要がある - デプロイパッケージに含めてLayerとして登録 - Runtime HTTP APIと実行するファンクションとのブリッジとして振る舞う - bootstrapがないとエラーになる - bootstrap作成 - Initialization Tasks - 請求時間とタイムアウト対象 - 関数変数読み取り - _HANDLER - ファンクションで設定されたロケーション、通常ファイル名.メソッド - LAMBDA_TASK_ROOT - ファンクションのコードを含むディレクトリ - AWS_LAMBDA_RUNTIME_API - Runtime APIのホスト名とポート - 関数の初期化 - ハンドラファイルを読み込み、グローバルスコープを処理 - SDKクライアントやDB接続などの静的リソースを作成して複数の呼び出しに再利用 - エラーハンドリング - エラー発生時は初期化エラーAPIをコール - Processing Tasks - ループイベントを待ち受ける形 - イベント取得 - トレーシングヘッダの伝播 - APIレスポンスに含まれるLambdaーRuntime-Trace−IDヘッダからX-Ray のトレーシングヘッダを取得 - _X_AMZN_TRACE_IDに値をセット - コンテキストオブジェクトを作成 - 関数のハンドラ呼び出し - レスポンスのハンドリング - エラーハンドリング - クリーンアップ 使い所は? - Lambdaがサポートしている言語の最新がない - Lambdaがサポートを打ち切った言語のバージョンを使い続けたい - Lambdaでサポートされていない言語 ※ランタイム起因のトラブルはサポート対象にならない モニタリング CloudWatch - invocations:Lambda実行回数で課金対象 - duration:実行時間msec(コールドスタートは含まれない) - errors:エラー回数 - throttles:同時実行数を超過した回数(緩和申請の目安) - X-Ray Lambdaが保証しているのは呼び出されたときに「最低1回実行」のみ つまり、複数回呼び出される可能性がある。 - アプリケーション側で冪等性を確保、検知できるようにする - s3やdynamodb使うとか ストリームベースでの監視/運用ポイント - IteratorAgetのAvgが大きくなっている場合は処理遅れが想定される - Lambda実行環境のスペックにより実行時間の短縮を考える - Kinesis Streamsのshardを分割 - Error metricsが上がった場合は処理がロックされている可能性がある - Lambdaプログラム改善 - Kinesis streamsの読み込みをlatest/timestampベースで再設定 - Streamの場合、Errorを挙げないように設計/テストをすることが重要 LambdaのSQS起動の注意 メッセージ到達時の挙動 5つのパラレルロングポーリング接続を使用してSQSキューのポーリングを開始、 メッセージ数 > 処理量の傾向が続き、最終的に処理が追いつかない場合、 同時実行数の上限までスケール Lambda関数単位に同時実行数を制限しない場合、アカウントの上限までスケールする可能性がある。 - 他のLambda関数の起動を妨げる可能性がある - 大規模に使用する際には対象のLambda関数に対して同時実行数の設定を検討する X−Rayデーモン - Lambda関数をトレースする場合、X-Rayデーモンが自動的に実行される。 - X-Rayデーモンによって最大16MB or 関数のメモリ割りて3% - Lambdaは関数のメモリ制限を超えないようにX-rayデーモンを終了しようとする - Lambda関数に128MB割当。X-Rayデーモンに16MBが割り当てられる。 - 128 - 16 = 112MBを超えるようだとデーモンを終了する
1日1%成長する ~Aws Lambda Part2~
AWSの学習メモ
- AWSのblackbaltの動画を15分以上毎日見る
- 動画を簡単にまとめる
Aws Lambda Part2 VPC Q&A プライベートIPアドレスを固定することは? -> ENIはLambdaによって作成・削除が自動的に行われるので不可能 グローバルIPアドレスを固定することは? -> VPCアクセスを有効にした時点でそのままインターネットへはアクセスできない アクセス元として特定Lambdaファンクションのみ許可は? -> Lambda関数に割り当てたセキュリティグループをソースとする許可ルール オンプレミスにあるリソースへアクセスしたい場合は? -> Direct ConnectやVPN レイテンシへの影響は? Lambda関数への初回アクセス時などENIの作成を伴う場合は10秒~60秒 ENIはLambda関数ごとに作成? ENIは複数のLambda関数から共用させる 同時実行数 アカウント単位:1000(デフォルト) 関数A:上限100 関数B:上限200 その他:上限700 ※DBへの書き込みや外部APIの呼び出しなどダウンストリームの流量制御や ENI/IPアドレスの利用量をコントロールしたい場合 環境変数 コードの変更なく設定した値を渡すことが可能 - DBの接続URLを本番、開発用の2種類のLambda関数で切り替え - key/valueのペア 関数のコードからのアクセスは各言語でサポート - Node.jsはprocess.envなど 暗号化 - KMSで暗号化される - 暗号化はデプロイプロセス後 - 関数が呼び出されると自動的に復号化される - 環境変数に機密情報を保存する場合はデプロイ前に暗号化することを強く推奨 - 暗号化ヘルパー利用 - 独自のサービスキーも利用可能(KMSの料金が適用される) 制限 - key/valueの合計サイズが4KB以下 - 文字は[a-zA-Z]で開始 - 利用可能な文字列は[a-zA-Z0-9_] バージョニング ある一時点のLambdaファンクションをバージョンとして管理可能 - 新しいバージョンはいつでも発行可能で、各バージョンには一意のARNがある - Lambdaファンクションの作成/更新時にpublishパラメータを追加する - PublishVersionを実行することで明示的に発行することも可能 - バージョンの発行をするまでは$LATESTが唯一のバージョンとなる - エイリアス(特定のバージョンに対するポインタ) Lambda Layres 共通コンポーネントをzipファイルにしてLambda Layersとしてアップロード Layersはimmutableであり、アップデート管理のためにバージョニング 5つまでLayersまで可能