SAA学習-サーバレス-サーバレスによるサービス化
今回のテーマ：サーバレスによるサービス化
概要
サーバレス化を実現することはAWSを活用する上で必要な観点になります。
振り返りとなりますが、5つの設計原則と11のベストプラクティスの関係図のおさらいで、概略図は以下になります。
サーバではなくサービス
11のベストプラクティスの1つにある「サーバではなくサービス」の考え方より、
マネージド型サービスとサーバレスアーキテクチャを活用し効率的な設計と運用を実現します。
AWSサービスで関連するサービスは以下のものが挙げられます。
関連するサービス
サーバレス化
サーバー(EC2インスタンス)ではなく、Lambdaなどのコンピュートサービスによりシステム構成をできる限り利用します。
現在のAWSアーキテクチャではサーバレス化を進める対応が基本とされております。
概略図は以下になります。
サーバレス化からサービス化
サーバレス設計により疎結合設計が加速します。
疎結合化によってマイクロサービス化されたシステムの構築が可能になります。
サービス化
従来のSOA方式から、小さなプロセス多淫のサービスをAPI連携したマイクロサービスで設計します。
SOAとマイクロサービスについては以下となります。
サービス指向アーキテクチャ(SOA)
- 一通り機能がそろった大きなサービス単位で、コンポーネントを分割する設計方式
- アプリケーションをコンポーネント化し、通信プロトコルによる連携で他のコンポーネントにサービスを提供するアーキテクチャ設計
- 例：年金システムであれば給付サービス/徴収サービス/適用サービスなど
マイクロサービス
また、疎結合化とマイクロサービス化は表裏一体の関係性にあります。
マイクロサービス化の例
大きなサービスを1つの作業が終了するコンテキスト単位に分割します。
サービスの内訳の例として以下の概略図で、赤字の範囲がマイクロサービスする対象となります。
API活用
マイクロサービスはAPI通信によりコンポーネント間を疎結合化して利用します。
サーバレス化のポイント
利用中のインスタンス本当に必要か設計を見直すことを忘れないすることが大切です。
例えば、メール送受信のみしか使用してないのにメールサーバーとして利用しているかなどあります。
今回のテーマは以上です。
SAA学習-サーバレス-SESの概要
今回のテーマ：SESの概要
概要
Amazon Simple Email Service(SES)は、
フルマネージド型/サーバレス型のコスト効率に優れたEメールサービスとなります。
要点は以下のようなものがあります。
- スケーラブルな構成で信頼性が高いマネージド型
- メール送信：トランザクションメールなどの高品質なコンテンツを顧客に送信可能
- メール受信：受信したメールをトリガーにS3やLambdaなどを起動可能
- バウンス処理：メールが送れなかった場合の処理を規定
SESのメール送信方法
メールサーバーとして利用するだけではなく、
アプリケーションから自動でメール送信や連携処理が利用可能です。
送信方法は以下の項目は以下があります。
HTTP REST API
- SendEmail API：From/To/Subject/Bodyだけ用意すればSES型でメッセージを生成し送信
- RendRawEmail API：メッセージ全体をアプリケーション側で生成し送信
- 認証：AWSアクセスキーとシークレットアクセスキーを使用
SMTPエンドポイント
- 生成済みEmailメッセージを受け取ってSESのSMTPエンドポイント経由しメールを送信
- SMTPを前提としたアプリケーションから直セス利用する場合利用
- 利用ポート
-25(SMTP)
-465(SMTP over SSL)
-587(Message Submission) - TLS(Transport Layer Security)が必要
- 認証：専用IAMユーザを作成しそのクレデンシャルを使用
SESのメール受信
SESのメール通知を利用してS3やLambdaなどと連携が可能です。
連携時の概略図は以下のようになります。
SES利用準備
事前にドメイン登録やAWS上で利用できるメールとするため、利用申請が必要となります。
AWS側に申請を通すリードタイムがあるため、利用する際は計画し事前対応をします。
今回のテーマは以上です。
SAA学習-サーバレス-SNSの概要
今回のテーマ：SNSの概要
主要サービスの公式資料
SNS：
概要
Amazon Simple Notification Service(Amazon SNS)はフルマネージド型のプッシュ型通知サービスで、
他のサービスとの非同期通信を可能とします。
概略図は以下のようになります。
送信側がトピックを作成し、受信側でポリシーを指定することで、制御された非同期通信を実現します。
実装する際は、SNSにてTopicの作成から実装となります。
概略図は以下のようになります。
SNSの特徴
AWSの様々なサービスと連携して通知可能で、疎結合アーキテクチャに利用できます。 要点は以下の項目が挙げられます。
- 単一発行メッセージ
- メッセージ通信順番は保証されない
- 取り消し不可
- 配信ポリシーによる再試行実施
- メッセージサイズは最大256KB
SNSとの連携
AWSのサービスと連携する項目は以下のものなどが挙げられます。
- Amazon CloudWatch：Billing Alertの通知
- Amazon SES：Bounce/Complaintのフィードバック通知
- Amazon S3：ファイルがアップロードされたときの通知
- Amazon Elastic Transcoder：動画変換処理完了/失敗時の通知
SNSとSQSの使い分け
SNSとSQSは処理方式が異なるため、利用シーンに応じて使い分けます。
以下は概要に比較項目になります。
| 項目 | SNS | SQS |
|---|---|---|
| メッセージ | 永続性なし | 永続性あり |
| 配信方式 | プッシュ型 | ポーリング型 |
| プロデゥーサー | 発行 | 送受信 |
| コンシューマー | サブスクライブ | 送受信 |
cf)プロデゥーサー キューにメッセージを送信するコンポーネント
cf)コンシューマー キューからメッセージを受信するコンポーネント
今回のテーマは以上です。
ドキュメント管理ツールのgit/TortoiseGitの導入
業務やプライベートで勉強する際、
避けては通れない壁の「git/github」を使用するため、
動作を勉強する上で実施してみました。
今回のテーマ：ドキュメント管理ツールのgit/TortoiseGitの導入
環境設定
- ローカルPCがWindowsなのでこちらで実施。
gitのインストール
公式サイトへアクセスします。
公式サイト：Git for Windows
公式サイト上から、Downloadをクリックします。
exeファイルのダウンロード確認します。
対象のexeファイルを選択し、右クリックから管理者として実行をクリック
※画面がうまくとりませんでしたので選択まで
ユーザーアカウント制御(UAC)を有効にしている場合、
確認ダイアログが表示されるため、はいをクリック
インストーラー起動後、利用規約が表示され確認後、Nextをクリック
インストール先のフォルダを指定し、Nextをクリック
※デフォルトのインストール先で問題ないです。
インストールするパッケージ選択し、Nextをクリック
※デフォルトのパッケージで問題ありません。
起動パスの名称を指定します。
gitを使用するエディターの指定し、Nextをクリック
今回は、VSCodeを活用するため選択をそちらへ変更します。
gitコマンドで接続時のカレントディレクトリの指定で、Nextをクリック
デフォルトの指定だとmasterがカレントになります。
Windows版なので、gitコマンドを実行する際の指定します。
Bash、unixではないため消去法で3rd-party softwareになります。
リモート接続時に使用する実行ツールを指定し、Nextをクリック
デフォルトのssh.exeを使用で問題ありません。
HTTPS接続する際、個別に鍵を使用してなければOpenSSLを指定し、Nextをクリック
gitのリポジトリと同期する際の文字コードの指定し、Nextをクリック
ターミナルの指定は、Windows標準のコマンドプロンプトを指定し、Nextをクリック
リポジトリと同期する「git pull」を実行する際同期方法を指定し、Nextをクリック デフォルトの標準指定で問題ありません。
接続時の認証情報の指定は特に指定ないので、Nextをクリック
個別オプション指定許可の設定で、デフォルトのままで、Nextをクリック
チェック入れなくても問題ありません。
個別オプションの許可選択で、指定はないため、Installをクリック
インストール完了を確認し、Finishをクリック
TortoiseGitのインストール
gitをGUIで管理するためツールに「TortoiseGit」というものがあり、無償ツールのためこちらを活用します。
公式サイトへアクセスします。
公式サイト：tortoisegit.org
公式サイト上から、Downloadをクリックします。
64bitのものを選択します。
インストーラを選択し、右クリックからインストールをクリック
setupの起動を確認し、Nextをクリック
利用規約を確認し、Nextをクリック
SSH接続するためのクライアントツールを選択し、Nextをクリック
インストール内容とインストール先選択し、Nextをクリック
Installをクリック
UACの状態ではダイアログ表示がありその場合、はいをクリック
インストール確認されたことを確認し、Finishをクリック
言語パッチ
言語パッチを選択し、パッチをダウンロードします。
言語パッチをダウンロード後、インストール
セットアップ起動後、次へをクリック
UACの状態ではダイアログ表示がありその場合、はいをクリック
言語設定ウィザードを起動するにチェックし、完了をクリック
初期設定
ローカルブランチとなるフォルダを作成します。
ローカルブランチのフォルダを右クリックし、Gitここにリポジトリ作成を選択します。
リポジトリ作成時の確認ダイアログでBareのチェックを外している状態で、OKをクリック
空のgitリポジトリとして初期化されたことを確認し、OKをクリック
ユーザー名とメールアドレスを登録が要求されるため、はいをクリック
TortoiseGit利用時の確認ダイアログが表示されるため、OKをクリック
名前とメールアドレスを記入後し、適用をクリック
初回コミット
ローカルブランチで試験用のファイルを作成し、フォルダに対しGtコミットを選択します。
アップロードするファイルとコメントを記入し、コミットをクリック
実行確認します。
cf)実務だと先にローカルブランチ側へ同期させてから実行する対応になると考えられます。
Amazon FSx On-Demand Workshopsを可能な限りコストで動かしてみた
実際のWorkshopリンク先：
無料枠を若干超えるため勉強コストに余裕がある際に実施した方がよいかと思います。
なお、WorkShopを実行する際はCloudFromationで実行するため、
概要を把握しておいた方がよいです。
構成図：
yamlファイルの編集
デモ用のCloudFomasionの指定先はTokyoリージョンにある「Deploy to aws」を選択します。
AWS マネージメントコンソールへログインし、
Cloud Formationのスタックの作成画面が表示されたら、
テンプレートのURLをブラウザで指定しyamlファイルをダウンロードします。
ダウンロードしたらファイルをエディタソフトで編集します。
InstanceTypeはデフォルトm5.largeのため、t2.micro(無料枠)に変更します。
また、FSxのストレージ容量のデフォルト指定は、5120GBのため、
実行要件で最低の2000GBを指定します。
補足：20GBを指定しましたが、CloudFromation実行後に、
最低2TB指定してくださいとありました。
～上記略～
Parameters:
AvailabilityZones:
Description: Select two (2) Availability Zones (AZ). One public subnet and one private subnet will be created in each AZ.
Type: List<AWS::EC2::AvailabilityZone::Name>
InstanceType:
AllowedValues:
- t2.micro
Default: t2.micro
Type: String
KeyPair:
Type: AWS::EC2::KeyPair::KeyName
VpcCidr:
AllowedValues:
- 10.0.0.0/16
- 173.31.0.0/16
- 192.168.0.0/16
Default: 10.0.0.0/16
Description: Select the private IPv4 CIDR for the VPC.
Type: String
～中略～
WindowsFileSystem:
Type: AWS::FSx::FileSystem
Properties:
FileSystemType: WINDOWS
StorageCapacity: 2000
StorageType: HDD
SubnetIds:
- !Ref PrivateSubnet0
- !Ref PrivateSubnet1
SecurityGroupIds:
- !Ref FileSystemSecurityGroup
Tags:
- Key: Name
Value: MAZ
以下略
変更終了後、CloudFromationの画面へ移動後に、
テンプレートファイルのアップロードを選択し先程更新したyamlファイルをアップロードします。
スタックの名称は任意で記載します。
なお、パラメータの指定は以下にします。
VPC CIDR：パブリックのCIDR Availability Zone：2つ設定 Instance Type：先程更新したt2.micro Key pair：便宜上表示してませんが、指定します。
※AZの指定は2つ指定します。
スタックオプション
Nameタグはあった方がよいのですが、
動作確認が主目的になるため指定なしで問題ありません。
詳細オプション
特に指定なしで問題ないため、次へをクリック
IAMリソースが作成されることを承認にチェックを入れて、
スタックの作成をクリック
スタックの情報より、ステータスがCREATE_COMPLETEと表示されていることを確認します。
cf)動作確認したら、CloudFormationから削除を実施すると作成したリソースがすべて削除されます。
SAA学習-サーバレス-SQSの概要
今回のテーマ：SQSの概要
AWSが提供するMessage Queueサービスが今回の内容です。
主要サービスの公式資料：
SQS： docs.aws.amazon.com
AWS Black Belt Online Seminar： www.youtube.com
Amazon Sinple Queue Service(SQS)
AWSが提供するプロセス間通信などのスレッド間通信に使われるコンポーネントで、制御やデータを伝達するポーリング型キューサービスとなります。
ポーリングとは
複数のプログラム間通信に対し、一定のタイミングの問い合わせがあった場合、送受信処理を行う通信方式となります。
概略図は以下のようになります。
直接通信の場合、受信側がBusyの状態だと処理が滞る可能性があります。
いったん中継所に通信内容を貯めておいて、受信側のタイミングが良いときに受信の通信を行います。
SQS
SQSはキューをため込んでポーリング処理を実施するサービスとなります。
メッセージデータを受信側が受け取るまでの概略図は以下のようになります。
また、SQSの内訳はRequestキューとResponseキューとなり、送受信をキューイングすることができます。
概略図は以下のようになります。
SQSの特徴
フルマネージド型で提供された高可用性/高スケーラビリティ/高スループット/低コストを実現します。
項目としては以下のようなものがあります。
- 複数のサーバー/データセンターにメッセージを保持する高可用性構成
- 多数の送信者と受信者に対応可能なスケーラビリティの確保
- メッセージが増加しても高いスループットを維持
- 無料枠と従量課金による低コスト
- 冗長化などの可用性はAWS側のサービスで構成
また、送受信するデータは256KBまでのデータしか利用できず、60秒から14日間メッセージを保持することができます。
項目は以下のようなものがあります。
| 項目 | 概要 |
|---|---|
| メッセージサイズ | メッセージの最大サイズは256KB Extended Client Libraryを利用すると2GBまでのメッセージ送受信が可能 |
| メッセージ保持期限 | 削除されないメッセージはデフォルトで4日間保持 保存期間は60秒から14日間の間で変更可 |
| In Flightメッセージ | 1つのキューごとに最大120,000In Flight(受信されたメッセージ&Visibility Timeout内)メッセージ |
キューのタイプ
SQSのキューメッセージの処理順序は、以下の2つの方式から選択します。
- 標準キュー(デフォルト)
- FIFO(First in First out)キュー
標準キュー(デフォルト)
標準キューは「順番通りに処理」と「1回だけのメッセージング」をなるべく早く実施する処理となります。
FIFO(First in First out)キュー
最初に入ったキューを最初に処理する順番を守るキューイングを実施する処理となります。
SQSの機能
追加機能を利用することでキューイング処理に工夫することが可能となります。
以下は追加機能の概要となります。
| 機能名 | 概要 |
|---|---|
| Short Poling | キューが空の場合、即時リターンを実行 |
| Long Poling | キューが空の場合、タイムアウトまで待ちを継続 |
| デッドレターキュー | ずっと残ったメッセージを別キューに移動し、正常に処理できなかったメッセージを隔離 |
| Visibility timeout | 新しいメッセージを指定時間見えなくする |
Visibility timeout
Visibility timeoutを設定することで、優先的に処理してほしい受信インスタンスを指定することが可能となります。
概略図は以下のようになります。
今回のテーマは以上です。
SAA学習-サーバレス-疎結合化の追求
今回のテーマ：疎結合化の追求
概要
5つの設計と11のベストプラクティスの対比よりサーバレスの観点は以下のオレンジ色の箇所となります。
コンポーネントの疎結合
コンポーネント間の相互依存を減らした構成を取ることにより、1つのコンポーネント変更や障害の影響を削減します。
プログラムの考え方だと構造を分ける認識になります。
なお、関連するAWSサービスは以下のようなものがあります。
- Lambda
- SQS
- ELB
- SNS
密結合の問題
密結合した構成は障害や修正に弱く不具合が発生しやすい傾向になります。
以下は密結合の概略図となります。
また、密結合のデメリットは以下ようなものがあります。
疎結合化のメリット
ELBやAPIなどを利用し、結合点を削減したりメッセージ結合にすることで影響を減らすことが可能となります。 以下は疎結合化した場合の概略図となります。
また、疎結合化のメリットとしては以下のようなものがあります。
- 耐障害性が高まる
- 負荷対応やスケーリングが容易
- システム構成の追加/変更が容易
疎結合化のサービス概要
サーバレス化をするサービスやメッセージング処理をするサービスを利用し疎結合化を行います。
以下はAWSサービスとその概要になります。
| AWSサービス | 概要 |
|---|---|
| ELB | サーバー間のトラフィック調整と連携をELBを起点することで疎結合化を実現する |
| SQS | SQSのキューイングによる通信でインスタンス間連携を結ぶことで疎結合化を実現 |
| SNS | SNSのアプリケーション間通信でインスタンス間連携を結ぶことで疎結合化を実現 |
| Lambda | サーバーインスタンスではなくLambdaによるトリガー処理を連携することで疎結合化を実現 |
通信系サービスによる疎結合
サーバー間の連携を直接結んで連携すると密結合となってしまいます。
概略図としては以下のようになります。
そのため、サーバー間の連携をメッセージング処理を結ぶことで疎結合化を実現します。
概略図としては以下のようになります。
疎結合化設計
疎結合化設計にはサーバーレス/キューイング通信/マネージド型サービスの利用を組み合わせて設計を行います。
以下は密結合タイプの設計パターンと疎結合化向けの設計パターンになります。
密結合タイプの設計パターン
疎結合化向けの設計パターン
- ユーザー認証/管理をIAMなどのマネージド型サービスを利用
- なるべくLambdaなどサーバレスでアプリケーションを構成
- アプリケーション間はSQSなどMQ(message Queueing)通信で連携
- 静的WEBシステムをVPC外部のS3に保存
今回のテーマは以上です。
