Udemy「手を動かしながら2週間で学ぶ AWS 基本から応用まで」Day12,13,14
どうも、はぐりんです。
一か月ぶりの更新となります。
炎上プロジェクトはどうなったかって？
怒号と罵声が飛び交うぐらい順調です（ハート）
喧嘩を止めてると「私、何してるのかしら？」って思いますよね。
さて、受講が滞っていたUdemyのAWS講座
https://www.udemy.com/aws-14days/
のDay12,13,14を一気に受講しましたので、
その内容メモを残したいと思います。
Day12 Eメール送受信サービスSESとキューイングサービスSQS
【Amazon Simple Email Service(SES)】
・フルマネージドなメール送受信サービス
・送信の特徴
→ AWSSDK経由でPGからメール送信を行うことが可能
→ 独自ドメインからメールを送れる
・受信の特徴
→ 独自ドメインを設定可能
→ 受信メールをS3に保存したり受信をトリガに後続処理を実施可能
・SESの利用方法（準備）
→ ドメインを登録する
→ Route53に紐づける
→ 利用緩和申請を行う（今回は行わない）
→ メールを事前登録する
→ マネジメントコンソールから送信する
→ SDKforPHPでメッセージを送信する
・SESは3つのリージョンからしか利用できない。
・初期設定
→ ドメイン登録（Route53にも登録される）
→ DKIMも有効にする。
→ 送信先メールを事前登録する。これで登録したアドレスにはメールを送れるようになる。
・マネジメントコンソールからテストメール送信
→ From：Route53に登録したドメイン（＠の前は自由に設定）
→ To：事前登録したアドレス
→ メール送信成功！
・プログラムからのメール送信
→ バッチサーバへメール送信PHPを実行
→ メール送信成功！
・SNSと組み合わせてメールが正しく送信できたかを取得することができる
【Amazon Simple Queue Service（SQS）】
・フルマネージドなキューイングサービス
・処理の間にQueueをかませるメリット
→ 非同期処理にできる、モジュール間を疎結合にできる
・SQSの機能
→ 一度に複数件のメッセージを登録・処理できる
・注意点
→ 順序は保障されない
→ 同じメッセージを複数回受信する可能性がある（FIFOキューを検討する）
→ FIFOキューの方が価格が高い
・SQSの利用方法
→ キューを作成する
→ マネジメントコンソールから送受信する
→ SDKforPHPでメッセージを送受信する
・プログラムからSQSを利用する
→ 作成したキューのURLを指定してキューの送受信
→ ※うまく動かないと思ったらリージョン間違えてた！
【コラム２】
３）ネイティブアプリ＋サーバレスAPIパターン
４）サーバレスSPAパターン＋サーバレスAPIパターン
５）Twitterボット＋サーバレスバッチパターン
→５）が、お手軽で面白そう！（課金も少ない模様）
Day13 アプリケーション開発を支援するCodeシリーズ
【Codeシリーズ】
・CodeCommit
→ ソースコードを管理するGitリポジトリサービス
・CodeBuild
→ ソースコードのビルド／テスティングサービス
・CodeDeploy
→ ビルドされたモジュールのデプロイサービス
・CodePipeline
→ 継続的デリバリー／継続的インテグレーションをサポートするサービス
【CodeCommit】
・フルマネージドなソースコード管理サービス
→ 簡単にGitリポジトリをホストすることができる。
→ プルリクエスト機能も利用できる
・利用するソースコードを準備する（＠バッチサーバ）
・リポジトリを作成する
→ マネージメントコンソールでリポジトリ作成
→ バッチサーバでgitの初期設定、初回のコミット。
（別途、gitの勉強をすること。今回は写経）
【CodeBuild・CodeDeploy】
・フルマネージドなビルドサービス
→ コンパイルやテスト環境を簡単に構築することができる。
→ 作業はbuildspec.yml（ヤムルと読む）
・成果物格納用S3バケットの作成
・buildspec.ymlファイルの準備
→ アプリケーション名、S3バケット名を登録。
・CodeBuildでプロジェクトの作成
→ 新しいロールに権限の付与
・デプロイ自動化サービス。S3にあるビルド済のアーティファクトをEC2やオンプレサーバにデプロイする。
→ デプロイ動作は、appspec.ymlに定義する。
→ デプロイ方式を選択可能
→ デプロイ先にエージェントをインストールする必要がある。
・１）EC2用のIAMロール作成
・２）EC2にCodeDeployエージェントをインストール
・３）CodeDeploy用のロール作成
・４）CodeDeployの設定
→ アプリケーション名（buildspec.yml）と合わせる
→ デプロイ先のインスタンスを指定（Webサーバ2つ）し、
ロードバランシングも有効にする。
（デプロイ時に切り離ししてくれる）
・ビルドの実行→デプロイの実行
・ビルド時間は約8分。うち6分は「BlockTraffic」という動作
→ これはロードバランサーが切り離すのに待つ時間。
ロードバランサーのターゲットグループで設定値を確認。
【CodePipeline】
・継続的デリバリーをサポートするサービス
・CodeCommit/CodeBuild/CodeDeployの流れをパイプラインとして定義することで
ソースコードがコミットされたらデプロイまで自動化。
→ デプロイ前にリーダーの承認を必須とするというルールも定義可能。
・CodePipelineの設定をして、
ソースコードを編集し、コミットすると自動でビルド、デプロイされることを確認。
Day14 CloudFormationを用いた環境構築の自動化
【AWSの環境構築自動化サービスについて】
・１）Elastic Beanstalk
→ 定番インフラ構成の自動構築およびAppデプロイの自動化サービス
→ ◎アプリ開発にリソース注力できる、×自由度は低い
・２）OpsWorks
→ Chefを利用した構成管理サービス
→ ◎Chefを既に利用している場合に最適、×OSより下のレイヤー
・３）CloudFormation
→ AWSのリソース管理・構築を自動化するサービス
→ ◎自由度が高く何でもできる、×OSより上のレイヤー
【CloudFormation】
・テンプレート：AWSリースの構成をYAMLorJSONで記載したドキュメント
・スタック：テンプレートから自動構築されたAWSリソースの集合
・テンプレート
→ セクション（Parameters、Mappings、Resources）
→ 組み込み関数（実行時に決まる動的な値）
・CloudFormationを使ってみる
→ １）テンプレートファイルの作成
→ CloudFormationにテンプレートファイルを渡す
→ 設定したVPCが自動で生成された
→ ２）Subnetの追加
→ テンプレートファイルの更新・アップロード。
→ 前回の差分を確認。
→ 更新。サブネットが自動生成されていることを確認。
※大文字と小文字を間違えてエラーになった。
→ ３）残りのネットワークまわりを仕上げる
→ ４）EC2のひな形を作る
→ ５）インスタンスタイプを実行時に選択できるようにする
→ ６）キーペアを登録する
→ キーペアはインスタンス作成時に埋め込むため、新規インスタンスが作成される
→ ７）MappingsセクションとFindInMap関数を使ってリージョンごとのAMIを選択する
・ベストプラクティス
→ １）組み込み関数を使って環境に依存しないテンプレートを目指す。
→ ２）リソース追加・変更は必ずCloudFormationで行う
→ ３）テンプレートをバージョン管理する
→ ４）システムの規模やライフサイクルによってテンプレートを分割する
→ ※JSON or YAML？
→ YAMLはコメントがかける、JSONよりカッコが少なくて済む。
今回の受講は約3時間でした。
受講を開始したのが10月頭なので、2週間の講座を丸々3か月かけて受講したことになります。
さて、講座は最後のDay15（まとめ）が残っているので、
次回の記事で受講をまとめたいと思います。
ではまた(´-ω-`)))ｺｯｸﾘｺｯｸﾘ｡｡
