サーバーレスについて
疎結合化の追求
コンポーネントの疎結合
コンポーネント間の疎結合依存を減らした構成とすることで１つのコンポーネント変更や障害の影響を削減する
・関連する主要サービス Lambda、SQS、ELB、SNS
密結合の問題
密結合したアーキテクチャは障害や修正に弱く、不具合が発生しやすい
【密結合はデメリットが多い】 ・１インスタンスの障害の影響が全体に及びやすい ・１つの修正対応で穂可能インスタンスへの影響を多く考慮しなければならない ・負荷対応やスケーリングなども容易にできない ・システム構成の追加、変更が難しい
疎結合化のメリット
ELBやAPIなどを利用して結合点を削減したりメッセージ結合にすることで影響を減らすことができる
【疎結合化のメリット】 ・耐障害性が強まる ・負荷対応やスケーリングなどが容易 ・システム構成の追加、変更が容易
疎結合化向けサービス
サーバーレス化をするサービスやメッセージング処理をするサービスを利用して疎結合化する
◾️ELB サーバー間のトラフィック調整と連携をELBを起点に結ぶことで疎結合化を実現
◾️SQS SQSのキューイングによる通信でインスタンス関連携を結ぶことで疎結合化を実現
◾️SNS SNSのアプリケーション間通信でインスタンス間連携を結ぶことで疎結合化を実現
◾️Lambda サーバーインスタンスではなくLambdaによるトリガー処理で連携することで疎結合化を実現
通信系サービスによる疎結合
サーバー間の連携を直接結んで連携すると密結合となってしまう
疎結合設計
疎結合設計にはサーバーレス / キューイング通信 / マネージド型サービスの利用などを駆使した設計を行う
◾️密結合タイプの設計パターン ・ユーザー認証、管理をバックエンドサーバーで処理 ・通常のEC2インスタンスでアプリケーションを構成 ・アプリケーション間では直接通信 ・静的ウェブシステムをEC2インスタンスEBSに保存
◾️疎結合化向けの設計パターン ・ユーザー認証、管理をIAMなどのマネージド型サービスを利用 ・なるべくLambdaなどサーバレスでアプリケーションを構成 ・アプリケーション間ではSQSなどMQ通信で連携 ・静的ウェブシステムをVPC外部のS3に保存
SQSの概要
Amazon Simple Queue Service（SQS） プロセス間通信などのスレッド間通信に使われるコンポーネントで制御やデータを伝達するポーリング型キューサービス
ポーリングとは
複数のプログラム間通信に対し、一定のタイミングの問い合わせがあった場合に送受信処理を行う通信方式 直接通信だと受信側がBusyな場合に処理が滞る可能性がある
一旦中継所に通信内容をためておいて受信側のタイミングがいい時に通信を行う
SQSはキューをため込んでポーリング処理を実施するサービス
RequestキューとResponseキューにより送受信をキューイングすることができる
SQSの特徴
フルマネージド型で提供され、高可用性・高スケーラビリティ・高スループット・低コストを実現
・複数のサーバー / データセンターにメッセージを保持する高可用性構成 ・多数の送信者と受信者に対応可能なスケーラビリティの確保 ・メッセージが増加しても高スループットを維持できる ・無料枠と従量課金による低コスト
基本的には２５６KBまでの軽いデータしか利用できず、６０秒か１４日間メッセージを保持する ◾️メッセージサイズ メッセージの最大サイズは２５６KB Extended Client Libraryを利用すると２GBまでのメッセージの送受信が可能
◾️メッセージ保持期間 削除されないメッセージはデフォルトで４日間保持 保持期間は６０秒から１４日間で変更可能
◾️InFlightメッセージ １つのキューごとに最大１２０,０００In Flight（受信されたメッセージ＆Visibility Timeout内）メッセージ
キューのタイプ
SQSのキューメッセージ処理順序は２つの方式から選択する
・標準キュー ・FIFO（First in First out）キュー
標準キュー
順番通りに処理と１回だけのメッセージングをなるべく実施する処理
FIFOキュー
その名の通り最初に入ったキューを最初に処理する順番を守るキューイングを実施
SQSの機能
追加機能を利用することでキューイング処理を工夫することができる
◾️Short Poling キューが空でも即時にリターンする
◾️Long Poling キューが空の場合はタイムアウトまで待つ
◾️デッドレターキュー ずっと残ったメッセージを別キューに移動し、正常に処理できなかったメッセージを隔離する
◾️Visibility timeout 新しいメッセージを指定時間見えなくする
Visibility timeout
Visibility timeoutを設定することで優先的に処理してほしい受信インスタンスを指定することが可能
SNSの概要
Amazon Simple Notification Service（SNS） Amazon SNSはフルマネージド型のプッシュ型通知サービスで他のサービスとの非同期通信を可能にする
送信側がトピックを作成して受信側をポリシー指定することで制御された非同期通信を実現する
SNSの特徴
AWSの様々なサービスと連携して通知可能で、疎結合アーキテクチャに利用できる
・単一発行メッセージ ・メッセージ通信順番は保証されない ・取り消し不可 ・配信ポリシーによる再試行を実施 ・メッセージサイズは最大２５６KB
・Amazon CloudWatch：Billing Alertの通知 ・Amazon SES：Bounce / Complaintのフィードバック通知 ・AmazonS3：ファイルがアップロードされた時の通知 ・Amazon Elastic Transcoder：動画変換処理完了 / 失敗時の通知
SNSとSQS
SNSとSQSはその処理方式が異なるため利用シーンに応じて使い分ける
◾️SNS ・メッセージは永続ではない ・プッシュ型配信方式 ・プロデューサーが発行 ・コンシューマーがサブスクライブ
◾️SQS ・メッセージは永続性あり ・ポーリング型配信方式 ・プロデューサーが送受信 ・コンシューマーが送受信
SESの概要
Amazon Sinple Email Service（SES） フルマネージド型 / サーバレス型のコスト効率に優れたEメールサービス
・スケーラブルな構成で信頼性が高いマネージド型 ・メール送信：トランザクションメールなどの高品質なコンテンツを顧客に送信可能 ・メール受信：受信したメールをトリガーにS3やLambdaなどを起動可能 ・バウンス処理：メールが送れなかった場合の処理を規定
SESのメール送信方法
単なるメールサーバーとして利用するだけでなく、アプリ自動でメール送信や連携処理に利用可能
◾️HTTP REST API ・SendEmail API：From / To / Subject / Bodyだけ用意すればSES側でメッセージを生成して送信する ・SendRawEmail API：メッセージ全体をアプリケーション側で生成して送信する ・認証：AWSアクセスキーとシークレットアクセスキーを使用
◾️SMTPエンドポイント ・生成済みEmailメッセージを受け取ってSESのSMTPエンドポイントを経由してメールを送信する SMTPを前提としてプログラムから直接利用する場合などに利用 ・利用ポート ー２５ ー４６５（SMTP over SSL） ー５８７（Message Submission） ・TLS（Transport Layer Security）が必要 ・認証：専用IAMユーザーを作成してそのクレデンシャルを使用
SESのメール受信
SESのメール通知を利用してS3やLambdaなどと連携が可能
SES利用準備
ドメイン登録やAWS上で利用できるメールとするための利用申請を事前にする必要がある
◾️ドメインを登録 ◾️メールの事前申請
サーバーレスによるサービス化
マネージド型サービスとサーバーレスアーキテクチャにより効率的な設計と運用を実現
・関連する主要サービス Lambda、SNS、SQS、ELB、SES、DynamoDB、AmazonAPIGateway、AmazonCognito
サーバレス化
サーバー（EC2インスタンス）ではなく、Lambdaなどのコンピュートサービスによるシステム構成をできる限り利用する
サーバレス化からサービス化へ
サーバレス設計によって疎結合設計が加速し、疎結合化によってマイクロサービス化されたアプリケーションが構築できる
サービス化
昔ながらのSOA方式から、より小さなプロセス単位のサービスをAPIで連携したマイクロサービスで設計する
◾️サービス指向アーキテクチャ（SOA） ・一通りの機能が揃った大きなサービス単位でコンポーネントを分割する設計方式 ・アプリケーションをコンポーネント化して通信プロトコルによる連携で他のコンポーネントにサービスを提供するアーキテクチャ設計 ・ex.年金システムであれば給付サービス、徴収サービス、適用サービスなど
◾️マイクロサービス ・SOAよりも小さな機能単位のプロセスでサービス化した構成 ・各プロセスでは１つの小さなタスクをサービスとして提供し、プロセス間通信はAPIを用いる
疎結合化とマイクロサービス化は表裏一体の関係となる
マイクロサービス化
大きなサービスを１つの作業が終了するコンテキスト単位に分割する
◾️SOAサービス ・保険料徴収サービス ・記録管理サービス ・年金適用サービス ・年金給付サービス
◾️マイクロサービス化 ・給付対象者決定業務 ・支払額算定業務 ・支払い決済業務
API活用
マイクロサービスはAPI通信によりコンポーネント間を疎結合化して利用される
サーバレス化のポイント
利用しているインスタンスが本当に必要か設計を見直す
Lambdaの概要
インフラを機にすることなくアプリケーションコードで実行できるデータ処理サービス
クライアントからのアクセスに対してデータを登録する単純な処理をEC2インスタンスに実行されていれば Lambdaに置き換えてサーバレスに実行処理することが可能
Lambdaの特徴
サーバレスによりEC2インスタンスの代わりコードを実行することで効率的なアーキテクチャを実現する
・実行基盤は全てAWSが管理 ・AWSサービスと連携させることで簡単にイベントドリブンなアプリケーションを実装可能 ・Node.js / Javaで書かれたコードを実行 ・１００ミリ単位でコード実行時間に対しての課金でありコスト効率が非常に高い ・オートスケール
Lambdaの仕組み
利用方法もシンプルでWEBアプリやモバイルアプリから簡単に利用可能
・Lambdaファンクションを用意する ・アプリからLambdaを呼び出す
イベント発生後に数ミリ秒以内にLambdaコードが実行される
・画像のアップロードをトリガーとして ・アプリケーション内の実行処理をトリガーとして ・ウェブサイトのクリックをトリガーとして ・接続デバイスからの出力をトリガーとして
Lambdaの起動
LambdaはPushモデルとPullモデルによって実行される
◾️Pushモデル S3 / Cognito / SNSなどのAWSサービスとカスタムイベントが直接実行することにより起動するLambdaファンクション ・サービスもしくはアプリが直接実行する ・順不同 ・３回までリトライ
◾️Pullモデル DynamoDBとKinesisなどのデータ処理はLambdaに対して直接的にイベント発行を行わないためLambdaがそれらへポーリングを行い自らイベントを取得 ・ストリームに入ってきた順に処理される ・イベントソースとして登録したストリームに対してLambdaが自動的にデータ取得などのファンクションを実行する ・イベントごとに複数レコードを取得可能 ・データが期限切れになるまでリトライ
Lambdaの起動：Pullモデル
Lambda自らがPullしてKinesisストリーム処理データのデータ項目を取得する
Lambdaの処理タイミング
他のAWSサービスやSDKを利用したモバイルもしくはWebアプリからの呼び出しが可能
◾️非同期実行 リクエストが正常に受け付けられたというレスポンス内容が返ってくる
◾️同期実行 実行完了時にLambdaファンクション内でセットしたレスポンスが返ってくる
Lambdaのパーミッション
Lambdaファンクション作成時にLambda側で自動で作成したり、クロスアカウントアクセスも設定可能
◾️Execution ・LambdaファンクションがAWSリソースにどういったアクションを実施させるかを決定する ・指定されたIAMロールにそってAWSのリソースへのアクセスが許可される
◾️Invocation ・Lambdaファンクションをどのリソースが実行できるかを決定する
Lambdaの連携
様々なAWSサービスをトリガーとして起動するなどの連携処理が可能 ・Amazon S3、Kinesis、DynamoDB Stream 、Cognito（Sync）、SNS、Skills Kit、SWF
Lambdaの設定
１、コードをアップロードする 直接エディタ記述 / S3インポート / Zip形式でアップロード ２、関数を設定 スケジュール関数は実行頻度を指定 イベント駆動型関数はイベントソースを指定 ３、必要なメモリ容量を指定する ４、タイムアウト時間を指定する ５、VPCアクセス用にVPCを指定する ６、関数を起動する
ブループリント
Lambdaファンクションをコーディングする際にサンプルコード集を利用することが可能
スケジュール機能
特定時刻をトリガーにしてLambdaファンクションを実行する
バージョニング
バージョンニング機能でのファンクションの一時点を記録管理することが可能
◾️バージョンの発行方法 ・Lambdaファンクションの作成や更新時にpublishパラメーターによりバージョンが発行される ・Publish Versionにより明示的にバージョンを発行することが可能
◾️バージョンの特徴 ・一度発行すると変更不可 ・単純にバージョン番号が増加する ・エイリアス（特定バージョンに対するポインタ）を設定して特定時点にマークすることが可能 ・エイリアスを作成することでバージョン番号を把握していなくても指定バージョンを呼び出せる
VPCアクセス
インターネットを経由せずにVPC内のAWSリソースへとアクセス可能になる
◾️VPC内のリソースへのアクセス ・AWSの全てのVPC内リソースなどへインタネットを経由せずにアクセスが可能 ・Elastic Network Interface（ENI）を利用して実現 ENIには指定したサブネットのIPがDHCPで動的に割り当てられる
◾️アクセス制御 ・VPC内リソースにアクセスさせたいLamdbaファンクションに対してVPCサブネットおよびセキュリティグループを指定 ・ファンクションに割り当てるIAM RoleにAWSLambdaVPCAccessExecutionRoleというポリシーをアタッチしておくこと
ロードバランサー機能
ALBのバックエンドにLambdaを呼び出すことが可能になり、WEBアプリにLambdaファンクションを組み込みやすくなった
Lambdaユースケース
Amazon Echoの音声処理をトリガーとしてAlexaスキルを呼び出す
S3内のCloudTrailのログ分析により異常を検知した場合に、Lambdaを起動してメール通知する
Lambda起動のスケーリング
Lambdaファンクションでストリーミングデータの傾向に応じてスケーリングのトリガーとなる
Lambdaモバイルアプリ
モバイルからの写真管理をLambdaを通じて実施するなどモバイル連携も容易
Lambdaエッジ
Lambdaの機能とCloudFrontのエッジロケーション処理の機能を合わせたサービス CloudFrontにLambda機能を連携し、世界中でインフラをユーザーに近いロケーションでコードを実行が可能になる
イベントに関連づけられてLambdaファンクションがエッジロケーションで実行されて実行結果を返答する
API Gatewayの概要
API（Application programming interface）はシステムとシステムをつなぐ連結器
APIを通じてリクエストとレスポンスにより、他サービスの機能やデータを呼び出すことができる
◾️専門的には ・APIはアプリケーションソフトウェア開発に利用される標準的なインターフェース群のこと ・中でもWEB APIはWEB上で他のサービスを呼び出す方式や取り決め
APIの活用
自社アプリ、サービスをAPI化して連携を目指す方法と、API化された他社アプリ、サービスを活用する方法がある
◾️自社アプリ・サービスのAPI公開 自社アプリ・サービスをAPI化して自社サービスとの連携してサービスを展開する
◾️他社アプリ・サービスのAPI活用 他社APIサービスを活用して自社事業と組み合わせたアプリやサービスを展開する
APIエコノミー
APIエコノミーと自社サービスやデータをAPI化して社内外連携を促進し、ビジネス領域・価値を拡大させるビジネス活動
API利用の必要事項
APIの活用のためにはAPIを効率的に構築・運用・保守が十分にできる必要がある
・APIの作成、API利用状況の監視、APIのバージョン管理、APIの認証・アクセス管理
API Gateway
API作成 / 管理をフルマネージド型サービスで提供
・最大数十万個のAPI同時呼び出し、受付が可能 ・アクセス制御の管理 ・DDoS攻撃対応やスロットリングによるバックエンド保護 ・EC2 / Lambda / 任意のウェブアプリケーションのワークロード処理を実行する ・Lambdaと密接に統合されている ・WebSocketを利用したリアルタイムかつ双方向通信のAPIも処理可能
