CI/CD-Terraform-簡単なapply/destroy
Bluid Infrastructure
今回のテーマ：Terraformで簡単なapply/destroy
拡張子 .tfファイル
- インフラ環境のリソース情報をHCL言語で記載
- Terraform実行時「.tf」ファイルを参照しリソースの作成
terraform.tfstate
- Terraformで管理しているリソース情報(非常に重要なファイル)
- Terraformでリソースを作成後、自動生成
- 2回目以降のTerraform実行時、.tfファイルの定義内容と差分チェック
- 消失するとTerraformでリソース管理不可
Terraformのコマンド
- init：Terraformの作業ディレクトリの初期化(gitのローカルリポジトリ定義)
- plan：リソース変更に加えず、変更箇所やエラーを確認
- apply：リソースの作成、変更を実施
- detroy：terraform.tfstateで管理しているリソース削除
作業ディレクトリ作成
terraformを構成情報の作業ディレクトリを作成します。
- WSLコンソールで、ディレクトリを作成します。
作成コマンド
mkdir /home/user/terraform
確認コマンド
ls -ld /home/user/terraform
Terraform実行の権限付与
Terraformには高い権限が必要ですが、認証情報の取り扱いには注意が必要です。
また、Terraform構成ファイル内へのハードコーディングは非推奨となります。
付与する権限のポイントは以下のものが挙げられます。
IAMユーザにMFAが付与されている場合
- TerraformではMFA認証は非サポート
- 別の方法でMFA認証を実施する必要あり(aws-mfaコマンドなど)
.tfファイルにリソース情報記載
使用するリソースをProviderで宣言が必要となります。
- WSLコンソールで、構成ファイルを作成します。
コマンド
vim /home/user/terraform/main.tf
実装内容
provider="aws"{
region = "ap-northeast-1"
}
実装内容の補足は以下となります。
| 実装値 | 概要 |
|---|---|
| provider="aws" | AWSリソースを指定 |
| region = "ap-northeast-1" | 使用するリージョンを指定 |
| version = "x.xx" | providerのバージョンを指定。 指定しない場合、最新バージョンを使用 |
リソース設定(resource構文)
VPCの作成時は以下のようになります。
また、リソース作成時の注意点として以下のようなものがあります。
- Terraformでは各リソースをリソースの種類とリソース名で管理するため、リソースの種類＋リソース名などの組み合わせはユニークであることが必要
- VPCは他の鄭ナンシーやClassickLink等の設定があり、Default値が定められているため、必要な設定を把握することが必要
コマンド
vim /home/user/terraform/terraform.tf
実装内容
resource "aws_vpc" "vpc"{
cidr_block = 10.1.0.0/16
enable_dns_hostnames = true
tags = {
Name = "dev-connect-vpc"
}
}
実装内容の補足は以下となります。
| 実装値 | 概要 |
|---|---|
| resource "aws_vpc" "vpc" | resourceブロックでリソースの種類"aws_vpc"を指定。 任意のリソース名"vpc"を記述 |
| cidr_block = 10.1.0.0/16 | vpcのCIDRを指定(必須項目) |
| enable_dns_hostnames = true | BPCのDNSホストを有効化(デフォルトは無効) |
| tags = { Name = "dev-connect-vpc" } |
VPCのタグ名を指定。 key = Name,Value = dev-connect-vpc |
他のリソース属性の参照
サブネット作成時のtfファイルの実装として以下のポイントがあります。
コマンド
vim /home/user/terraform/terraform.tf
実装内容
resource "aws_subnet" "public_a"{
vpc_id = aws_vpc.vpc.id
cidr_block = 10.1.0.0/24
availability_zone = ap-northeast-1a
map_public_ip_on_launch = true
tags = {
Name = "dev-connect-public-a-subnet"
}
}
実装内容の補足は以下となります。
| 実装値 | 概要 |
|---|---|
| vpc_id = aws_vpc.vpc.id | VPCのIDを指定 aws_vpc.vpc：VPCリソースを指定 .id：VPC ID属性を参照 |
fmtコマンド
- 構成ファイルがあるカレントで実行
- 「.tf」ファイルを整形
コマンド
terraform fmt
initコマンド
- 構成ファイルがあるカレントで実行
- 指定したProvider情報を取得
- 基本的に初回のみだが、terraform.tfで設定した内容に変更がある際は再度実行
コマンド
terraform init
planコマンド
- 構成ファイルがあるカレントで実行
- デプロイ前のドライランを実行
コマンド
terraform plan
applyコマンド
- 構成ファイルがあるカレントで実行
- デプロイの実行
コマンド
terraform apply
destroyコマンド
- 構成ファイルがあるカレントで実行
- デプロイした環境を終了(壊す)
終了前のコマンド
terraform plan -destroy
終了コマンド
terraform destroy
今回のテーマは以上です。
CI/CD-Windows環境上でTerraformの準備
Terraformとは、HashiCorp社が提供する構成管理ツールとなります。
特徴は以下のようなものがあります。
- インフラ環境の構築や変更、削除の実施
- 独自の構成言語(HCL)を使用 (HCL：HashiCorp Configuration Language)
- 開発が活発されており、AWS/GCP/Azureなどの様々なIaaS/PaaS/SaaSで使用可能
Terraformの公式サイト
今回のテーマ：Windows環境でTerraformのインストール準備
WSL(Windows Subsystem for Linux)の準備
- クライアント側のWSL有効化するために、powershellより以下コマンドを実行
コマンド：
wsl --install
Microsoft Storeへアクセスし、入手をクリック
アクセス先：https://www.microsoft.com/ja-jp/p/ubuntu-2004-lts/9n6svws3rx71#activetab=pivot:overviewtabWSLの有効化を反映するため、クライアントを再起動
Microsoft Storeより、起動をクリックしWSLを起動
WSLの初期設定
- WSLコンソール起動後、UNIXアカウントを登録
ユーザー名：user
パスワード：任意
- WSLコンソールで、ubuntusのアップデートを以下のコマンドで実行
sudo apt update && sudo apt upgrade
- WSLコンソールで、日本語パッケージを導入するため、以下のコマンドを実行
sudo apt install language-pack-ja
- WSLコンソールで、日本語を有効効果するため、以下のコマンドを実行
適用コマンド
sudo update-locale LANG=ja_JP.UTF8
言語リスト反映確認コマンド
locale -a
言語パッチを反映したか確認するため、WSLコンソールを一度終了
クライアントよりスタート-Ubuntu 20.0.04 LTSを選択し起動
起動後、日本語化適用されているか以下コマンドで確認
echo $LANG
unzipのインストール
- WSLコンソールより、以下コマンドを実行しインストール
sudo apt install unzip
awscliインストール、awscli接続情報登録
- WSLコンソールより、以下コマンドを実行し、awscliv2をダウンロード
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
- WSLコンソールより、ダウンロードしたzipファイルの解凍を以下コマンドで実施
unzip awscliv2.zip
- WSLコンソールより、以下コマンドでawscliをインストールし、バージョンを確認
インストール
sudo ./aws/install
バージョン確認
aws --version
- WSLコンソールより、以下コマンドでawsへ接続するため接続情報を登録
登録実行コマンド
aws configure
※事前にAWSマネージメントコンソールより、
該当ユーザーのアクセスキー/シークレットアクセスキーの払い出しを実施
登録内容
AWS Access Key ID [None]: (AWSマネージメントコンソールより払い出し時確認) AWS Secret Access Key [None]: (AWSマネージメントコンソールより払い出し時確認) Default region name [None]: ap-northeast-1 Default output format [None]: json
- WSLコンソールより、以下コマンドでawsへの接続確認
aws sts get-caller-identity --query Account --output text
結果：
接続先のAWSアカウントの表示
brewのインストール
tfenvを導入するため、パッケージ構成管理ツールの「Homebrew」をインストールします。
- WSLコンソールより、前提パッケージのインストール
sudo apt-get install build-essential curl file git
- WSLコンソールより、brewのインストール
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
test -d ~/.linuxbrew && eval $(~/.linuxbrew/bin/brew shellenv) test -d /home/linuxbrew/.linuxbrew && eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)" test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile
- WSLコンソールより、brewコマンドのパス正常確認
brew doctor
Terraformのインストール/バージョン確認など
- WSLコンソールより、Terraformのインストール
brew install terraform
- WSLコンソールより、Terraformのバージョン確認
terraform --version
tfenvのインストール/バージョン確認など
- WSLコンソールより、terraformのリンクを削除
brew unlink terraform
- WSLコンソールより、terraformの管理ツールtfenvをインストール
brew install tfenv
- WSLコンソールより、tfenvのリンク付与
brew link --overwrite tfenv
- WSLコンソールより、tfenvのバージョン確認
tfenv --version
Terraformのバージョン指定(ここは共通バージョンを指定が必要)
- WSLコンソールより、terraformのバージョンをインストール
tfenv install 1.0.10
- WSLコンソールより、使用するterraformを指定
tfenv use 1.0.10
- WSLコンソールより、使用するterraformを確認
tfenv list
今回のテーマは以上です。
SAA学習-環境の自動化-イノベーションノウハウ
今回のテーマ：イノベーションノウハウ
概要
テクノロジー進化への対応
テクノロジーの進化とビジネス変化のスピードに対応するため、柔軟で素早いサービス開発が求められます。
例えば、「テクノロジー×ビジネスのスピード対応」や「多様な顧客ニーズへの対応」が挙げられます。
テクノロジー×ビジネスのスピード対応の背景は以下のようになります。
多様な顧客ニーズへの対応の背景は以下のようになります。
- 多様な顧客ニーズに柔軟かつスピーディに対応する必要性
- デザイン思考/リーンスタートアップなどの顧客中心手法が主流化
- 本当に使用するシステムだけ開発・運用する必要性
それらの背景があり、ビジネスに即応できる開発手法・技術の導入が必要となってきております。
事例：UBER
タクシー利用者としての体験
タクシーに乗ろうとしたが、なかなかタクシーが見つからない見つけた課題
必要な時に、最も近くにいるタクシーを手配出来たら便利では？技術による解決
データ×IoT/AIを活用し、ユーザーのスマホGPSとタクシーの位置情報を機械学習でマッチングすれば解決可能ではと仮説を設定
デザイン思考
デザイン思考ではユーザーを観察することで、問題を発見します。
発見した問題に対し、プロトタイプのテストを繰り返すしアイデアを具体化します。
以下はデザイン思考のプロセスの概略図となります。
リーンスタートアップ
リーンスタートアップとは、アイデアから最低限の製品など構築し、試行・計測を実施後、学習を経て再構築を実施します。
以下はリーンスタートアップの概略図となります。
また、リーンスタートアップを計画する際、リーンキャンパスを作成し、都度ブラッシュアップすることでビジネスモデルを構築します。
以下はリーンキャンパスの概略図となります。
アジャイル開発
デザイン思考やリーンスタートアップでビジネスモデルを構築する方法として、
アジャイル開発にて実施します。
アジャイル開発は、顧客要件の柔軟な受け入れと素早い開発で実施していきます。
なお、開発手法ではウォーターフォール型とアジャイル開発の2種があります。
以前は、小規模Web向けに利用されてましたが、
現在は基幹系も活用されるべく方法論が展開されつつあります。
これまでのアジャイル
これからのアジャイル
SOAからマイクロサービス/APIエコノミーへ
ERPなどのエンタープライズシステムはサービス単体で機能開発するService Oriented Architectureから小規模探知のマイクロサービスへ発展
マイクロサービスAPIを連携させることでAPIエコノミーが拡大小規模Web開発からエンタープライズ領域へ拡大
マイクロサービス開発にアジャイル開発が適用されて、柔軟な機能開発を実施
マイクロサービス化・API化により、ERPなど基幹系にもアジャイルが適用可能
将来的にエンタープライズアジャイルが主流になると予測されております。
DevOps
DevOpsとはDevelopment(開発)とOperation(運用)を相互連携させる体制・仕組みを作り変更を迅速に実施します。
これまでの開発と運用
開発と運用が別チームで、組織文化や仕事の仕方が異なり、衝突が多く素早い変更が困難DevOps
開発チームと運用チームで人材・文化を共有し、自動化ツールが共有され迅速な対応が可能
DepOpsでは一体化した組織文化を基盤として、自動化ツールを運用と開発で共有した体制を構築します。
以下はポイントについて記載します。
ツール
自動化されたインフラストラクチャ
AnsibleやChef、Dockerなどのツールでインフラ構築を自動化バージョン管理システムの共有
GitやMercurialなどでバージョン管理システムを共有ワンステップによるビルドとデプロイ
JenkinsやCapistranoを用いてビルドやデプロイを自動化フィーチャーフラグ
コード中の機能の有効/無効を設定ファイルで管理メトリクスの共有
New RelicやApplication Insightsなどで取得したメトリクス結果をダッシュボードで共有IRCとインスタントメッセージのコミュニケーション共有
SlackやHipChatなどのチャットツールに自動的にビルドやデプロイのログ・アラート内容が投稿され情報共有
組織文化
お互いを尊重/信頼/失敗に対し健全な態度/非難しない
まとめ
顧客起点/テクノロジー起点イノベーションには、デザイン思考、リーンスタットアップ、アジャイル開発/DevOpsを活用しながら実施していくことが求められます。
以下は概略図となります。
今回のテーマは以上です。
Docker＆Kubernetes-ローカル勉強環境の構築
Dockerとは
Kubernetesとは
今回のテーマ：Docker＆Kubernetesを動作するローカル勉強環境の構築
環境概要
ローカルPC内に仮想化マシンアプリケーションを導入し、仮想マシン上で環境を構築します。
環境の構成は以下のようになります。
Docker＆Kubernetesの環境構築
環境構築する場合の手順の概要は以下のようになります。
1.Dockerインストール 2.kubectlコマンドインストール 3.minikubeインストール 4.OSファイアーウォール停止 5.Kubernetes起動 6.アドオン追加
0.仮想マシンのIP確認
コマンド
ip -f inet a
実行結果
NICが付与されているIPアドレスを使用するため、確認しておきます。
デフォルトの状態ですとSSHでログインができず、VirtualBox側の設定を更新する必要があります。
参考記事
VirtualBox 上の CentOS に ssh 接続する [ Windows 編] - Resty's log:手取り15万円の日常
1.Dockerインストール
コマンド：
sed -i -e "/timeout\=/d" /etc/yum.conf sed -i -e "13s/^/timeout=300\n/g" /etc/yum.conf sed -i -e "/ip_resolve\=/d" /etc/yum.conf sed -i -e "14s/^/ip_resolve=4\n/g" /etc/yum.conf
オリジナルとの差分
13,14d12 < timeout=300 < ip_resolve=4
コマンド：
yum install -y \ yum-utils-1.1.31
コマンド：
yum-config-manager \
--add-repo \
https://download.docker.com/linux/centos/docker-ce.repo
- Dockerのインストール
コマンド：
yum install -y \ docker-ce-20.10.7 \ docker-ce-cli-20.10.7 \ containerd.io-1.4.6
- Dockerの自動起動とサービスの開始
コマンド：
systemctl enable docker systemctl start docker
- Dockerサービスの停止
コマンド：
systemctl stop docker
- Dockerの構成ファイルの設定
mkdir -p /etc/docker
DOCKER_IF_NAME=docker0
DOCKER_IF_ADDRESS=$(ip -4 address show ${DOCKER_IF_NAME} | grep inet | awk '{print $2}' | sed -e "s/\/[0-9]*$//")
DOCKER_LOCAL_REGISTRY=${DOCKER_IF_ADDRESS}:5000
cat <<EOF > /etc/docker/daemon.json
{
"dns": ["8.8.8.8"],
"insecure-registries": ["${DOCKER_LOCAL_REGISTRY}"]
}
EOF
- Dockerサービスの開始
systemctl start docker
2.kubectlコマンドインストール
コマンド：
curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.21.2/bin/linux/amd64/kubectl chmod +x ./kubectl mv -f ./kubectl /usr/local/bin
3.minikubeインストール
curl -Lo minikube https://storage.googleapis.com/minikube/releases/v1.21.0/minikube-linux-amd64 chmod +x minikube install minikube /usr/local/bin rm -f minikube
4.OSファイアーウォール停止
systemctl disable firewalld systemctl stop firewalld
5.Kubernetes起動
コマンド：
systemctl restart docker
6.アドオン追加
/usr/local/bin/minikube config set insecure-registry ${DOCKER_LOCAL_REGISTRY}
/usr/local/bin/minikube start --vm-driver=none
/usr/local/bin/minikube addons enable ingress
今回のテーマは以上です。
SAA学習-サーバレス-小テスト
単元の小テストを実施となります。
今回のテーマ：サーバレス-小テスト
設問1：
SQSについて誤っているものは何か。
回答：
デットレターキューは残ったメッセージを定期的に削除する
解説：
残ったメッセージを別キューに移動し、正常に処理できなかったメッセージを隔離します。
設問2：
SQSの特徴として正しいものは何か。
回答：
メッセージ保持期間は最大で14日に設定可能
解説
削除されないメッセージはデフォルトで4日間保持します。
保持期間は60秒から14日の間で変更可能です。
設問3：
SNSの特徴として正しいものは何か。
回答：
SNSは送信側がトピックを作成し、受信側をポリシーを指定することで制御された非同期通信を実現します。
解説：
なし
設問4：
コンポーネント感の通信を非同期でコンシューマー側の状況に応じて通信を実現したい場合、どのサービスを活用するか。
回答：
SQS
解説：
SQSを利用し、コンシューマー側から状況に応じてメッセージを取得する方式にする必要があります。
設問5：
SESの特徴として誤っている内容は何か。
回答：
Eメールメッセージを利用するため、必ずSESを利用する必要がある
解説：
SNSでもメール通信は可能です。
設問6：
回答：
最大数1000個のAPIを同時呼び出し・受付が可能である。
解説：
最大数十万個のAPIを同時呼び出し・受付が可能です。
設問7：
Lambdaの特徴として正しい内容は何か。
回答：
SDKを利用しアプリケーションに組み込むことができる。
解説：
なし
設問8：
LambdaのPushモデル/Pullモデルの正しい内容は何か。
回答：
Pushモデルは3回リトライを実行する
解説：
なし
設問9：
Lambdaのパーミッションについて正しい内容は何か。
回答：
Execution RoleによりLambdaがその他リソースで実行できる内容を設定する
解説：
Execution RoleによりLambdaがS3やDynamoDBなどのその他AWSリソースで実行できる許可設定を行います。
設問10：
Lambdaの機能について誤っているものは何か。
回答：
ブループリントを利用してファンクションコードを自動生成できる
解説：
ブループリントはユースケースごとのサンプルコードを参照することができる。
今回のテーマは以上です。
SAA学習-サーバレス-API GateWayの概要
公式サイトのURL：
APIとは
API(Application programming interface)は、システムとシステムをつなぐ連結器となります。
概略図は以下のようになります。
また、APIを通してリクエスト/レスポンス通信により、他のサービスの機能やデータを呼び出すことが可能です。
なお、一般的には以下のよう扱いとなります。
- APIはアプリケーションソフトウェア開発に利用される標準的なインターフェース群のこと
- Web APIはWeb上で他のサービスを呼び出す方式や取り決めのこと
APIの活用
APIの活用として、自社アプリ・サービスをAPI化し連携を目指す方式とAPI化された他社アプリ・サービスを活用する方式があります。 各々の概要について以下ようになります。
自社アプリ・サービスをAPI公開
- 自社アプリ・サービスをAPI化し、他社との連携しサービスと展開
他社アプリ・サービスのAPI活用
- 他社APIサービスを活用し、自社事業と組み合わたアプリやサービスを展開
APIエコノミー
APIエコノミーとは、自社サービスやデータをAPI化し社内外連携を促進し、ビジネス領域や価値を拡大させるビジネス活動となります。
API利用の必要事項
APIを活用するためには、APIを効率的に構築/運用/保守ができる状態であることが必要です。
項目としては以下のようなものが挙げられます。
API Gateway
API Gatewayとは、API作成/管理をフルマネージド型サービスでAWSが提供しています。
概要としては以下のようなものが挙げられます。
- 最大数十万個のAPI同時呼び出し・受付が可能
- アクセス制御の管理
- DDoS攻撃対応やスロットリングによるバックエンド保護
- EC2Lambda/任意のWebアプリケーションのワークロード処理を実行
- Lambdaと密接に統合
- WebSocketを利用したリアルタイムかつ双方向通信のAPIも処理可能
ユースケース
使用事例として、API Gatewayを連携口とし外部アプリとの連携を実現します。
簡易構成は以下のようなものがあります。
AWSにおけるAPI提供
一般的なアプリケーションの開発ではELB経由でAPIを提供します。
API GatewayはLambda関数を主とした簡易アプリケーション用のAPI提供に特化します。
API Gatewayのタイプ
API Gatewayのタイプは、通信方式に応じて利用を選択します。
利用できるタイプは以下の3種類となります。
HTTP API
RESTful API
- バックエンドのHTTPエンドポイント、Lambda関数、その他AWSのサービスに使用
- 主に同期通信に依存するアプリケーションに利用
- REST APIはクライアントサービスにリクエスト送信し、サービスが同期的に応答するリクエスト/レスポンスモデルに使用
WebSocket API
- 双方向用の通信方式
- チャットアプリ、コラボレーションプラットフォーム、マルチプレイヤーゲーム、金融取引基盤などのリアルタイムアプリに利用
API Gatewayの料金
API Gatewayの料金はAPI Gatewayタイプに応じて形式が異なります。
- HTTP API：使用したAPIコール分だけ料金発生
- RESTful API：受信したAPIコールと転送データ量に対してのみ料金発生
- WebSocket API：送受信したメッセージ数及び分単位の接続合計時間から料金発生
API Gatewayの統合
API GatewayはAPIメソッドを作成し、Lambda関数やWebサイトなどバックエンドポイントと統合します。
この際の統合タイプが以下の4つとなります。
Lambda統合
- Lambda関数との統合方式
- プロキシ統合またはLambda非プロキシ統合を使用し、APIメソッドをLambda関数に統合
Lambdaプロキシ統合
- API Gatewayがクライアントリクエスト全体をバックエンドLambda関数にマッピングし、Lambda関数と統合
- API Gatewayに許可ロールを設定し、統合設定することで自動的にマッピング統合が可能
- クライアントがAPIリクエスト送信するとAPI Gatewayは統合されたLambda関数にrawリクエストを渡し、リクエストパラメータの順序は保持されない
- リクエストデータには、リクエストヘッダー、クエリ文字列パラメータ、URLパス変数、ペイロードおよびAPI設定データを含む
- 設定データは、現在のデプロイステージ名、ステージ変数、ユーザーIDまたは承認コンテキストを含む
Lambda非プロキシ統合
HTTP統合
- バックエンドのHTTPエンドポイントを公開
- HTTPプロキシ統合またはHTTPカスタム統合を使用し、APIメソッドをHTTPエンドポイントに統合
- 利用ポート：80、443、1024-65535
プライベート統合
Mock統合
- バックエンド統合することがなくAPI Gatewayから直接APIレスポンスを生成する統合方式
- APIを操作する必要がある他の依存チームのブロックを解除可
- APIの概要やAPIへのナビゲーションを提供できるAPIライディングページをプロビジョンすることが可能
APIエンドポイントのタイプ
APIエンドポイントタイプは、APIトラフィックの発信元に応じて、エッジ最適化、リージョン別またはプライベートを選択します。
エッジ最適化APIエンドポイント
- CloudFrontと連携し、グローバルにクライアントが分散している場合、最適にルーティング
- APIリクエストは債よりのCloudFront POP(Point Pf Presence)にルーティング
- CloudFrontは、リクエストをオリジンに転送する前に、Cookie名の自然な順序でHTTP Cookieを並べ替える
リージョナルAPIエンドポイント
プライベートAPIエンドポイント
- VPC内のクライアントに最適なルーティング
- VPCからしかアクセスできないAPIエンドポイント
- インターフェースVPCエンドポイントにはVPC内に作成するエンドポイントインターインターフェースを利用
- リソースポリシーを利用し、アクセス制御が可能
キャッシュ機能の利用
APIのリソースのパフォーマンス向上の1つにキャッシュ機能の利用があります。
キャッシュ機能はエンドポイントへの呼び出しの数を減らしてAPIリクエストのレイテンシーを短くすることが可能です。
以下はキャッシュのTTLの設定に関する内容です。
スロットリングの利用
APIのリソースのパフォーマンス向上のもう1つにスロットリングの利用があります。
スロットリングとは、リクエスト数が多すぎる場合に制限をかけることで、トラフィック急増に対しバックエンドサービスを守ることが可能です。
以下はスロットリング制限が可能な方法になります。
サーバー側のスロットリング制限
クラアントあたりのスロットリング制限
- クライアントごとに「使用量プラン」に応じて制限を実施
- 特定のユーザーからのリクエストが多い場合は有効
API Gatewayの認証方式
API Gatewayへのアクセス認証は、以下のように様々なタイプを利用可能です。
リソースポリシー(REST APIのみ)
IAM認証
Lambdaオーソライザー
- Lambda関数を作成することで、認証プロバイダーでの認証結果をもとにAPIへのアクセス制限をメソッド単位で実施
Cognitoオーソライザー
- 認証プロバイダとしてCognitoユーザープールを用いて、APIへのアクセス制御をメソッド単位で実施
今回のテーマは以上です。
SAA学習-サーバレス-Lambdaの概要
今回のテーマ：Lambdaの概要
主要サービスの公式資料
Lambda： aws.amazon.com
Lambdaのクォータ仕様： docs.aws.amazon.com
AWS Black Belt Online Seminar：
概要
AWS Lambdaの仕組み
Lambdaとは、インフラを気にすることなくアプリケーションコードを実行できるデータ処理サービスとなります。
例えば、クライアントからEC2インスタンス経由でデータ登録する単純な動作をしている場合、
Lambdaに置き換えてサーバレスに実行処理をすることが可能です。
概略図は以下のようになります。
Lambdaの特徴
サーバレスによりEC2インスタンスの代わりにコードを実行することで効率的なアーキテクチャを実現します。
ポイントしては以下のようなものが挙げられます。
- 実行基盤はすべてAWSが管理
- AWSサービスと連携させることで簡単にイベントトリブンなアプリケーションを実行可能
- Node.js/Javaなどで書かれたコードを実行(他の言語はpythonもあります。)
- 100ミリ秒単位で、コード実行時間に対しの課金
- コスト効率が非常に高い
- オートスケール
Lambdaの仕組み
利用方法もシンプルで、WEBアプリやモバイルアプリから利用可能となります。
仕組みの概要は以下の2ステップとなります。
- STEP1：Lambdaファンクションを用意
- STEP2：アプリからLambdaを呼び出す
また、イベント発生後に数ミリ秒以内にLambdaコードが実行されます。
トリガーとする項目は以下のようなものが挙げられます。
- 画像アップロード
- アプリケーション内の実行処理
- WEBサイトのクリック
- 接続デバイスからの出力
Lambdaの起動
Lambdaの起動は、Pushモデル/Pullモデルによって実行されます。
Pushモデル
S3/Cognito/SNSなどAWSサービスとカスタムイベントが直接実行することにより、起動するLambdaファンクションとなります。
ポイントは以下のようなものが挙げられます。
- サービスもしくはアプリが直接実行
- 実行時は順不同
- 3回までリトライ
Pullモデル
DynamoDBとKinesisなどのデータ処理は、Lambdaに対し直接的なイベント発行を行いません。
そのため、Lambdaがそれらのポーリングを行い自らイベントを取得します。
ポイントは以下のようなものが挙げられます。
- ストリームに入ってきた順に処理
- イベントソースで登録したストリームに対し、Lambdaが自動的にデータ取得などのファンクションを実行
- イベントごとに複数レコードを取得可能
- データが期限切れになるまでリトライ
また、Lambdaが自らPullしてKinesisストリームの処理データの項目を取得します。
概要図は以下のようになります。
Lambdaの処理タイミング
Lambdaの処理タイミングは、他のAWSサービスやSDKを利用したモバイルアプリもしくはWebアプリからの呼び出しが可能です。
実行タイミングは以下の2種類があります。
非同期実行
- リクエストが正常に受け付けられたというレスポンス内容が返ってくること
同期実行
- 実行完了時にLambdaファンクション内でセットしたレスポンスが返ってくること
Lambdaのパーミッション
Lambdaのパーミッション(アクセス許可)は、Lambdaファンクション作成時にLambda側で自動作成したり、クロスアカウントアクセスも設定可能です。
アクセス許可の設定は以下の2種類があります。
Execution
Invocation
- Lambdaファンクションをどのリソースが実行できるか決定
Lambdaの連携
Lambdaが連携するAWSサービスとして以下のようなものが挙げられます。
- Amazon S3
- Amazon Kinesis
- Amazon DynamoDB Streams
- Amazon Cognito(Sync)：認証
- Amazon SNS
- Alexa Skills Kit
- Amazon SWF
Lambdaの設定
Lambdaを設定する方法として以下のような流れになります。
1.コードをアップロードする -直接エディタ記述/S3インポート/zip形式でアップロード 2.関数を設定 -スケジュール関数は実行頻度を指定 -イベント駆動型関数はイベントソースを指定 3.必要なメモリ容量を指定 4.タイムアウト時間を指定 5.VPCアクセス用にVPCを指定 6.関数を起動
ブループリント
ブループリントとは、Lambdaファンクションをコーディングする際、サンプルコードになります。
活用する際のポイントは以下のようになります。
- Lambdaを利用するユースケースを設計
- ブループリントにサンプルコードを検索
- サンプルコードを修正し、Lambdaファンクションを作成
スケジュール機能
スケジュール機能は、特定時刻をトリガーにしてLambdaファンクションを実行します。
バージョニング
バージョニングは、ファンクションの一時店を記録管理することが可能となります。
発行方法や特徴のポイントは以下のようになります。
バージョンの発行方法
- Lambdaファンクションの作成/更新時にpublishパラメータによりバージョンが発行
- PublicshVersionにより明示的にバージョン発行が可能
バージョンの特徴
- 一度発行すると変更不可
- 単純にバージョン番号が増加
- 特定バージョンに対するポインタ(エイリアス)を設定し、特定時点にマークが可能
- エイリアスを作成することでバージョン番号を把握してなくても指定バージョンを呼び出すことが可能
VPCアクセス
インターネットを経由せずVPC内のAWSリソースへアクセス可能となります。 概要としては以下のようなものがあります。
VPC内リソースへのアクセス
- AWSのすべてのVPC内リソースへインターネットを経由せずアクセスが可能
- Elastic Network Interface(ENI)を利用し実現
- ENIは指定したサブネットのIPがDHCPで動的に割り当て
アクセス制御
- VPC内リソースにアクセスさせたいLambdaファンクションに対し、VPCサブネットおよびセキュリティグループを指定
- ファンクションに割り当てるIAM Roleに「AWSLambdaVPCAccessExecutioRole」のポリシーをアタッチが必要
Lambda Layer(2018年 re:invent)
Lambdaファンクション間で共有するコンポーネントをLambda Layerとして定義し参照が可能です。
Lambda Layerは最大5つまでとなります。
概要図は以下のようになります。
ロードバランサー機能(2018年 re:invent)
ALBのバックエンドにLambdaを呼び出すことが可能となり、WebアプリにLambdaファンクションを組込み易くなりました。
概要図は以下のようになります。
その他Lambdaのユースケース(使用事例)
- Alexa：Amazon Echoの音声処理をトリガーとして、Alexaスキルを呼び出し
- ログの異常検知：S3内のCloudTrailのログ分析により異常検知した場合、Lambdaを起動しメール通知
- ストリーミング：Lambdaファンクションでストリーミングデータの傾向に応じスケーリングを実施
- モバイルアプリ：モバイルから写真管理をLambdaを通し実施するなども容易
Lambdaエッジ
Lambdaの機能とCloudFrontのエッジロケーション処理の機能を合わせたサービスとなります。
イベントに関連されたLambdaファンクションが、エッジロケーションで実行されて実行結果を返答します。
概要図は以下のようになります。
公式サイト： aws.amazon.com
今回のテーマは以上です。
