おっさん社内SEエンジニアの勉強ブログ

勉強記録のブログとなります。

SAA学習-環境の自動化-AWSの環境自動化サービス

今回のテーマ：AWSの環境自動化サービス

主要サービスの公式資料

Auto Scaling： docs.aws.amazon.com

Cloud Formation： docs.aws.amazon.com

CodeCommit： docs.aws.amazon.com

CodeBuild： docs.aws.amazon.com

CodeDeploy： docs.aws.amazon.com

ECS： docs.aws.amazon.com

Elastic Beanstalk： docs.aws.amazon.com

OpsWorks： docs.aws.amazon.com

SystemManager Run Command： docs.aws.amazon.com

スコープ

5つの設計原則と11のベストプラクティスより環境の自動化のスコープの概略図は以下のようになります。

f:id:In-houseSE:20211109160515p:plain

主要サービス

AWSで環境の自動化を行うサービスとして以下のものが挙げられます。

  • Auto Scaling
  • Cloud Formation
  • Code シリーズ
  • ECS
  • Elastic Beanstalk
  • OpsWorks
  • SystemManager Run Command

目的

環境を自動化することで開発速度を高め、DevOpsとCI/CDによる開発を実現します。

クラウドファーストの時代背景

テクノロジー×ビジネスに柔軟に対応するため、クラウドファーストが必要不可欠となります。
概略図は以下のようになります。

f:id:In-houseSE:20211109160540p:plain

また、リーンによる素早いサービス検討とCI/CDによる素早い開発をマイクロサービスに対し実施します。
概略図は以下のようになります。

f:id:In-houseSE:20211109160608p:plain

環境自動化サービス

AWSでは、DevOpsを実現する環境自動化サービスを豊富に提供されております。
概略図は以下のようになります。

f:id:In-houseSE:20211109160742p:plain

環境自動化サービスの概要は以下のようになります。

サービス名 概要
Codeシリーズ 開発コードのgit上のコミット・実行・デプロイを自動。
PipelineはCloudFormation/ECSのデプロイ自動化にも利用可能
Elastic Beanstalk Webアプリやサービスを使い慣れたサーバーでデプロイやスケーリングをするサービス
OpsWorks ChefやPuppetのマネージド型インスタンスのサーバー設定・デプロイ・管理を自動できるようになる設定管理サービス
CloudFormation クラウド環境内のすべてのインフラストラクチャリソースを記述し、
プロビジョニングするためテンプレート化されたプロビジョニングサービス
Amazon ECS AWS上でDockerコンテナによる環境構築のテンプレート化するサービス
DockerFile開発イメージを設定したインフラ設定をコード化
CloudWatch EC2インスタンスやEBSボリューム・DBインスタンス、カスタムメトリクスなどリソースを簡単にモニタリング

Codeシリーズ

Codeシリーズは、開発コードをgitベースのリポジトリ上で、コミット・実行・デプロイを自動化する一連のサービスとなります。 概略図は以下のようになります。

f:id:In-houseSE:20211109160805p:plain

Elastic Beanstalk

Elastic Beanstalkは、Webアプリケーションの定番構成の構築・デプロイの自動化サービスとなります。
ポイントは以下のようなものがあります。

  • 速く簡単にアプリをデプロイするサービス
  • Java,PHP,Ruby,Python,Node,js,.Net,Docker,Goの開発言語に対応し、Webアプリを展開
  • Apatch,Nginx,Passenger,IISなどのWebサービスでデプロイ
  • コードをアップロードすれば、キャパシティのプロビジョニング、ロードバランシング、Auto Scalingからアプリケーションのヘルスチェックまでデプロイを自動化

Elastic Beanstalkの構成用途

Elastic Beanstalkの構成用途として、アプリケーション単位にバージョン・環境設定をコードし、保存されて環境にバージョンが展開されます。
項目としては以下のものが挙げられます。

項目 概要
アプリケーション ・トップレベルの論理単位でバージョン/環境/環境設定が含まれる要素
バージョン ・デプロイ可能なコードでS3で管理
・異なる環境/異なるバージョンを展開可能
環境 ・各環境(Webサーバー/ワーカー)に応じて構築されるインフラ環境
・バージョン(ソースコード)をデプロイ
環境設定 その環境に関連するリソースの動作を定義する設定パラメータ
・永続データの格納場所はS3やRDSなどの外部サービスを利用

Elastic Beanstalkのユースケース

Elastic Beanstalkのユースケースは、Webアプリケーションのデプロイを容易にすることやタスクの長いワークロード展開に利用します。 Webサーバー環境とワーカー環境では以下のようになります。

Webサーバー環境
  • ELB+Auto Scalingでスケーラブルな構成をコード化し、バージョン管理を実施
  • スケーラブルなWebアプリケーションを実行の実現
  • 単一コンテナのDockerコンテナを実行可能
  • 複数コンテナはECSを使用した環境実行が可能
ワーカー環境
  • SQS+Auto Scalingでスケーラブルなバッチ処理ワークを実現
  • 定期的なタスク実行基盤の作成：毎日深夜1時に動作するバックアップ処理
  • ワーカーホスト内でWebアプリケーションを動作させワークロードの時間がかかる処理を実行

OpsWorks

OpsWorksは、ChefやPuppetによるインフラ設定・運用の仕組みをAWS上でマネージド型サービスとして提供してます。
AWS上で使用できるサービスは以下になります。

  • OpsWorksスタック
  • OpsWorks for Chef Automation
  • OpsWorks for Puppet Enterprise

OpsWorks for Chef Automation

OpsWorks for Chef Automationは、Chefサーバーを作成し、継続的なデプロイメントおよびコンプライアンスチェックの完全マネージド型サーバーサービスとなります。
サービスの概要としては以下のものがあります。

  • Chef Automaionは、Chefのcookbookやレシピを利用しインフラ管理を自動化するサービス
  • インフラおよびアプリの継続的なデリバリーパイプラインを構成することが可能
  • リソースはChefサーバーから構成内容のアップデートを取得
  • オペレーション/コンプライアンス/ワークフローイベントを可視化
  • AWSでChefサーバを構築でき、Chef Automate APIやChef DKなどのツールを利用

OpsWorks for Puppet Enterprise

OpsWorks for Puppet Enterpriseは、フルマネージド側Puppetマスターにより、アプリケーションのテスト/展開/運用を自動します。
サービスの概要としては以下のものがあります。

  • Puppetマスターは、インフラないノードを管理し、ノード情報を保存とPuppetモジュールの中央リポジトリ
  • Puppetマスターは、以下のタスクを処理する全スタック自動可
    • ソフトウェア
    • OS設定
    • パッケージのインストール
    • データベース設定
    • 変更管理
    • ポリシー適用
    • モニタリング
    • 品質保障
  • モジュールは、インフラストラクチャの設定方法に関する手順を格納したPuppetコードを再利用および共有が可能とするユニット
  • Puppetを使用し、EC2やオンプレミスデバイスにあたるノードの設定/デプロイ/管理方法を自動化

OpsWorksスタック

OpsWorksスタックは、スタックとアプリケーションの作成/管理のため、シンプルで柔軟な方法を提供するAWSのオリジナルサービスとなります。
サービスの概要としては以下のものがあります。

  • スタック/レイヤー/インスタンス/アプリケーションと呼ばれるコンポーネントによりモデル化を実施
  • コードで構成管理やオートスケーリングが可能
  • Linux/Windowsサーバをサポート
  • ライフライクルイベントによるタスクの自動化が可能
  • OpsWorksエージェントがChef Clientのローカルモードでレシピを実行
  • スタックがOpsWorksのトップエンティティである全インスタンスの構成要素をJSON形式で管理
  • AWS OpsWorksスタックはChefサーバ不要

Elastic BeanstalkとOpsWorksの違い

Webアプリのデプロイに特化したElastic Beanstalkに対し、OpsWorksは様々なアプリケーションに対応する高度なインフラ環境構築が可能です。

  • Elastic Beanstalk
    アプリケーションのデプロイ自動化
    Webアプリケーションやサービスを使い慣れたサーバーにおいてデプロイとスケーリングをするためのサービスとなります。

  • OpsWorks
    インフラの設定自動化
    ChefやPuppetのマネージド型インスタンスのサーバー設定/デプロイ/管理を自動化できるようになるインフラの設定管理サービスとなります。

CloudFormation

CloudFormationは、AWSクラウド環境内の全インフラリソースを記述しテンプレート化して展開する環境自動設定サービスとなります。
ポイントは以下のものがあります。

  • プロビジョニングされたリソースの変更/削除が可能
  • 追加リソースは通常課金のみで追加料金なし(CloudFromationのみなら)
  • JSON/YAMLで記述
  • クロスリージョンとクロスアカウントで管理
  • 直接サポートされていないリソースや機能を利用する場合、カスタムリソースでスタック作成の一部に独自ロジックを組み込むことが可能

コンテナ

コンテナは、ホストマシンのカーネルを利用し、プロセスやユーザーなどを蚊瓜する仮想化方式となります。 イメージ図としては以下のようになります。

f:id:In-houseSE:20211109160914p:plain

Docker

Dockerは、コンテナ側の仮想環境を作成/配布/実行するためのプラットフォームとなります。
ポイントは以下のものが挙げられます。

  • コード化されたファイルを共有するため誰でも同じ環境構築が容易に可能
  • 作成した環境を配布教諭が容易
  • 環境の即時構築/削除が容易なため、CI/CDによる開発が可能

AWSのコンテサービス

AWSで使用できるコンテナサービスとして以下のものがあります。

種別 AWSサービス名 概要
レジストリ Amazon ECR コンテナエンジンに実行されるイメージを保管
コントロールプレーン Amazon ECS/EKS コンテナを管理するサービス
データプレーン AWS Fargate コンテナが実行される環境

Amazon ECS

Amazon ECS(Elastic Container Service)は、Dockerコンテナをサポートする拡張性とパフォーマンスに優れたコンテナオートストレーションサービスとなります。
ポイントは以下のものが挙げられます。

  • コンテナ化されたアプリをAWSにおいて簡単に実行およびスケール可能
  • Fargateを利用することでコンテナのデプロイと管理サーバーのプロビジョニングや管理は不要
  • あらゆる種類のコンテナ可されたアプリケーションを簡単に作成可
  • Dockerコンテナの数が多くても数秒で起動可能
  • ELB/VPC/IAM/ECR/CloudWatch/CloudFormation/CloudTrailなどのAWSサービスを利用可
  • VPCネットワークモードで、TaskごとにENIを自動割り当てし、Security GroupをTaskごとに設定可
  • VPC内の他リソースへPrivete IPで通信が可能
  • Fargate起動タイプとEC2起動タイプの2種類のモード

Amazon ECR

Amazon ECR(Elastic Container Registry)は、フルマネージド型のレジストリサービスでDockerコンテナイメージを簡単に保存/管理/デプロイすることが可能です。
ポイントは以下のものが挙げられます。

  • ECSとDocker CLIに統合されており、開発から本稼働までのワークフローを簡略化
  • IAMによる協力な認証管理機構
  • エンドポイントにアクセスできるならAWS外からでも利用可能
  • ライフサイクルポリシーでイメージの自動クリーンアップ
  • VPCネットワークモードでタスクごとにENIを自動割り当てし、さらにセキュリティグループをタスクごとに設定可能

Amazon EKS

Amazon EKS(Elastic Kubernetes Service)は、コンテナ化されたアプリケーションのデプロイ/管理/スケールをオープンソースのKubernetesを使用し実行するサービスとなります。
ポイントは以下のものが挙げられます。

  • Kubernetesは、自動デプロイ/スケーリング/アプリ/コンテナの運用自動化のため設計されたオープンソースプラットフォーム
  • Kubernetesのパートナーやコミュニティが作成した既存のプラグインやツールを使用可能
  • マネージド側サービスであり、コントロールプレーンの管理不要
  • ワーカーノードとマネージドコントロールプレーンとの間に、暗号化処理された安全な通信チャネルを自動的にセットアップ
  • Kubernetes環境で管理されるアプリケーションと完全な互換性

AWS Fargate

AWS Fargateは、サーバーやクラスターの管理なしにコンテナを実行するECSに対応したコンピュータエンジンとなります。 起動モードは2種類あり以下のものになります。

EC2起動モード
  • ECSでEC2インスタンスを起動
  • コンテナアプリケーションを実行するインフラストラクチャに対し、サーバーレベルの詳細なコントロールを実行可能
  • サーバークラスタを管理し、サーバーでのコンテナ配置をスケジュール可能
  • サーバークラスターでのカスタマイズの幅広いオプションの利用可能
Fargate起動モード
  • ECSで設置できる専用のコンピューティングエンジン(2019年12月よりEKSも対応可)
  • EC2インスタンスのクラスター管理は不要
  • インスタンスタイプの選択/クラスタースケジューリング管理/クラスター使用の最適化は不要
  • CPUやメモリなどアプリ要件を定義すると必要なスケーリングやインフラはFargateが管理
  • 秒で数万個のコンテナを起動

CodePipeline × CloudFormation の連携

CloudFromationで設定したAWS環境に対し、CodePipelineを使うことでテンプレートの変更/実行/展開を自動化できます。

CodePipeline × ECS の連携

ECSで設定したDocker環境に対し、CodePipelineを使用することでテンプレートの変更/実行/展開を自動化できます。

今回のテーマは以上です。

CI/CD-Terraform-簡単なapply/destroy

Bluid Infrastructure

learn.hashicorp.com

今回のテーマ：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を構成情報の作業ディレクトリを作成します。

作成コマンド

mkdir /home/user/terraform

確認コマンド

ls -ld /home/user/terraform

Terraform実行の権限付与

Terraformには高い権限が必要ですが、認証情報の取り扱いには注意が必要です。
また、Terraform構成ファイル内へのハードコーディングは非推奨となります。
付与する権限のポイントは以下のものが挙げられます。

  • リソース作成権限を持ったIAMユーザの認証情報(環境変数やaws cliなど)
  • リソース作成権限を付与したIAMロール(EC2やCodBuildなど)

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ファイルの実装として以下のポイントがあります。

  • 作成時、VPC IDが必要
  • VPCリソースからVPC IDを参照

コマンド

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の公式サイト

www.terraform.io

今回のテーマ：Windows環境でTerraformのインストール準備

WSL(Windows Subsystem for Linux)の準備

  • クライアント側のWSL有効化するために、powershellより以下コマンドを実行

コマンド：

wsl --install

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とタクシーの位置情報を機械学習でマッチングすれば解決可能ではと仮説を設定

デザイン思考

デザイン思考ではユーザーを観察することで、問題を発見します。
発見した問題に対し、プロトタイプのテストを繰り返すしアイデアを具体化します。
以下はデザイン思考のプロセスの概略図となります。

f:id:In-houseSE:20211101073006p:plain

リーンスタートアップ

リーンスタートアップとは、アイデアから最低限の製品など構築し、試行・計測を実施後、学習を経て再構築を実施します。
以下はリーンスタートアップの概略図となります。

f:id:In-houseSE:20211101074450p:plain

また、リーンスタートアップを計画する際、リーンキャンパスを作成し、都度ブラッシュアップすることでビジネスモデルを構築します。
以下はリーンキャンパスの概略図となります。

f:id:In-houseSE:20211101075358p:plain

アジャイル開発

デザイン思考やリーンスタートアップでビジネスモデルを構築する方法として、
アジャイル開発にて実施します。
アジャイル開発は、顧客要件の柔軟な受け入れと素早い開発で実施していきます。
なお、開発手法ではウォーターフォール型とアジャイル開発の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を活用しながら実施していくことが求められます。
以下は概略図となります。

f:id:In-houseSE:20211101083140p:plain

今回のテーマは以上です。

Docker＆Kubernetes-ローカル勉強環境の構築

Dockerとは

www.redhat.com

Kubernetesとは

www.redhat.com

今回のテーマ：Docker＆Kubernetesを動作するローカル勉強環境の構築

環境概要

ローカルPC内に仮想化マシンアプリケーションを導入し、仮想マシン上で環境を構築します。
環境の構成は以下のようになります。

f:id:In-houseSE:20211017162252p:plain

Docker＆Kubernetesの環境構築

環境構築する場合の手順の概要は以下のようになります。

1.Dockerインストール
2.kubectlコマンドインストール
3.minikubeインストール
4.OSファイアーウォール停止
5.Kubernetes起動
6.アドオン追加

0.仮想マシンのIP確認

コマンド

ip -f inet a

実行結果

f:id:In-houseSE:20211017162737p:plain

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

コマンド：

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：

API Gatewayの特徴として誤っている内容は何か。

回答：

最大数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の概要

API Gatewayの仕組み

APIの仕組み

公式サイトのURL： https://aws.amazon.com/jp/api-gateway/:embed:cite

今回のテーマ：API Gatewayの概要

APIとは

API（Application Programming Interface）は、システム間をつなぐインターフェースです。 概略図は以下のとおりです。

API概略図

APIを通してリクエスト／レスポンス通信を行い、他のサービスの機能やデータを呼び出すことが可能です。 一般的には以下のように分類されます：

  • API：アプリケーション開発に使われる標準的なインターフェース群
  • Web API：Web上で他のサービスを呼び出すための方式や規約

APIの活用

APIの活用方法には、自社サービスをAPIとして公開する方法と、他社のAPIを利用する方法があります。概要は以下の通りです。

自社アプリ・サービスをAPI公開

  • 自社サービスをAPI化し、他社と連携してサービス展開

他社アプリ・サービスのAPI活用

  • 他社のAPIを活用し、自社のアプリやサービスに組み込み展開

APIエコノミー

APIエコノミーとは、自社のサービスやデータをAPI化し、社内外での連携を促進することで、ビジネスの幅や価値を拡大する取り組みです。

API利用の必要事項

APIを活用するには、効率的に構築・運用・保守できる体制が必要です。主な要素は以下の通りです。

  • APIの作成
  • 利用状況の監視
  • バージョン管理
  • 認証とアクセス管理

API Gateway

API Gatewayは、AWSが提供するフルマネージド型のAPI作成・管理サービスです。特徴は以下の通りです：

  • 数十万件の同時APIリクエスト処理が可能
  • アクセス制御機能
  • DDoS対策やスロットリングによるバックエンド保護
  • EC2／Lambda／任意Webアプリとの連携
  • Lambdaとの高い統合性
  • WebSocketを用いたリアルタイムな双方向通信も可能

ユースケース

API Gatewayを外部アプリケーションとの連携に用いることで、連携口として機能します。 以下は簡易構成図です。

ユースケース構成図

AWSにおけるAPI提供

一般的なアプリケーションでは、ELB（Elastic Load Balancing）経由でAPIを提供します。

ELB構成図

API Gatewayは、Lambda関数をベースにした軽量なアプリケーションのAPI提供に特化しています。

API GatewayとLambda構成

API Gatewayのタイプ

API Gatewayは以下の3タイプから選択できます（通信方式に応じて使い分けます）。

HTTP API

RESTful API

  • Lambda関数や各種AWSサービス、HTTPバックエンドに対応
  • 同期通信向け（クライアント → サービス → 応答）

WebSocket API

  • 双方向通信を必要とするリアルタイムアプリ向け（例：チャット、ゲーム、金融取引）

API Gatewayの料金

料金はAPIタイプにより異なります。

  • HTTP API：リクエスト数に応じて課金
  • RESTful API：リクエスト数と転送データ量に応じて課金
  • WebSocket API：メッセージ数および接続時間に応じて課金

API Gatewayの統合

API Gatewayは以下の統合方式でバックエンドと接続します。

Lambda統合

Lambdaプロキシ統合

  • クライアントのリクエストをそのままLambdaに渡す形式
  • リクエストヘッダー、クエリ、パス、ボディなどすべての情報を受け取れる

Lambda非プロキシ統合

  • リクエスト内容やレスポンス形式を個別にマッピング可能
  • 細かい制御をしたい場合に有効

HTTP統合

  • 任意のHTTPエンドポイントと統合（ポート80, 443, 1024〜65535）

プライベート統合

  • VPC外からVPC内リソースへのアクセス
  • 認証方式と組み合わせて制御

Mock統合

  • バックエンドなしでAPI Gateway自身がレスポンス生成
  • スタブ用途や開発チームのテスト用に便利

APIエンドポイントのタイプ

トラフィックの発信元に応じて、以下の3タイプから選択します。

エッジ最適化エンドポイント

  • CloudFrontと連携し、世界中のクライアントに最適ルーティング

リージョン別エンドポイント

  • 同一リージョン内での利用に最適。CloudFrontとの併用も可

プライベートエンドポイント

  • VPC内からのみアクセス可能なエンドポイント
  • VPCエンドポイントやリソースポリシーでアクセス制御

キャッシュ機能の利用

API Gatewayはキャッシュ機能を持ち、リクエストの数を減らしてレイテンシーを低減できます。

  • デフォルトTTL：300秒
  • 最大TTL：3600秒
  • TTL=0でキャッシュ無効化

スロットリングの利用

スロットリングはリクエスト数を制限し、バックエンドを保護します。

サーバー側スロットリング

  • すべてのクライアントに対して制限をかける方法

クライアント単位スロットリング

  • クライアントごとの「使用量プラン」に基づいて制限

API Gatewayの認証方式

以下の認証方式に対応しています：

リソースポリシー（REST API専用）

  • JSON形式でアクセス許可／拒否を定義

IAM認証

  • IAMユーザー・ロールに対しアクセス制御を設定

Lambdaオーソライザー

  • Lambda関数で外部認証結果を検証し、アクセスを許可

Cognitoオーソライザー

  • Cognitoユーザープールでユーザー認証を実施

以上が「API Gatewayの概要」の説明です。 ご希望に応じて、この内容の出力形式変更（PDFやスライド用など）も可能です。