EC2 の イベントウィンドウとは 例えば RDS などのマネージドサービスの場合、サービサーである AWS 側の都合で、メンテナンスによる インスタンスの再起動などが必要になるケースがあるのは、比較的よく知られており、意識して運用設計がされる面だと思います。 一方で、表題の EC2の場合には、これまで、この AWS 側都合による再起動について、ユーザ側の事前のコントロールはあまり効かない状況でした。 なお、以前から存在した機能としては、EC2で 既にスケジュールされたイベントの開始時間を変更出来る API は存在していました。こちらについては、以下の ブログ記事に詳しくまとまっています。 再起動がともなうAmazon EC2のスケジュールイベントの開始時間を変更出来る機能がリリースされました。 ただし、上記は、AWS による スケジュールイベント が設定された後に操作が必要であり、「事前に準備しておく」ような運用をするには、まだ一歩足りない機能だったように感じます。 今回、この AWS 側都合による EC2 のメンテナンスによる再起動を、ユーザ側でスケジューリングできる機能が追加されました。 AWS からの アナウンスは、以下のブログに掲載されています。 Amazon EC2 now supports custom time windows for Scheduled Events 仕様についての説明は、以下の URL に掲載されています。 Define event windows for scheduled events こまごまとした仕様は、上記の Considerations を参照するのがよさそうです。 なお、記事 執筆時点(2021年7月)で、いずれも 日本語版は存在していないようです。 本記事で伝えたいポイントは以上なのですが、せっかくなので、多少機能を触ってみたいと思います。 マネジメントコンソール上では、EC2 コンソール の上部にある「イベント」メニューから、「アクション」ドロッブダウンを選択し、「イベントウィンドウを管理」メニューを選択することで、イベントウィンドウの管理画面を選択することができます。 マネジメントコンソール上からの操作は難しくない(ハズ)なので、以下では、(例によって)CLIでの操作で イベントウィンドウ の機能を見ていきます。 CLIバージョン v1 系 では、1.20.0 で、v2 系では、2.2.20 で、それぞれ、イベントウィンドウを操作する機能が取り込まれています。 以下の記事では、version 2.2.22 で実行した動作をベースに CLI を紹介します。 C:\Users\yoichi> aws --version aws-cli/2.2.22 Python/3.8.8 Windows/10 exe/AMD64 prompt/off CLI 概観 イベントウィンドウ に関する CLI は、以下の6つが用意されています。 create-instance-event-window : イベントウィンドウを作成します。 パラメータ : --time-range パラメーター、または --cron-expression パラメータを指定して、再起動可能なイベントウィンドウを作成します。 --time-range と --cron-expression は、いずれか片方を 排他で設定する必要があります。 delete-instance-event-window : イベントウィンドウを削除します。 modify-instance-event-start-time : イベントウィンドウの設定を変更します。 describe-instance-event-windows : イベントウィンドウの設定を表示します。 パラメータ : イベントウィンドウの指定には、イベントウィンドウの ID (instance-event-window-id) を直接指定する以外にも、 associate-instance-event-window で関連付けた instance-tag や dedicated-host-id でフィルタすることもできるようです。 associate-instance-event-window : 作成したイベントウィンドウを EC2 インスタンスに関連付けます。 パラメータ : 関連付けの際には、イベントウィンドウの ID (instance-event-window-id) と ターゲットの指定が必要です。 ターゲットには、インスタンスID(InstanceIds) 、専用ホストID(DedicatedHostIds)、またはインスタンスタグ(InstanceTags) のいずれか 1種のみが指定できます。 イベントウィンドウに関連付けることができる個数に上限が設けられている(インスタンスID : 最大100個、専用ホストID : 50個、インスタンスタグ : 50個)ため、できるだけ、個数上限を気にしない運用をしたい場合には、インスタンスタグ による指定が推奨、という感じでしょうか。 disassociate-instance-event-window : イベントウィンドウと、ターゲット の関連付けを解除します。 やってみる : イベントウィンドウの作成 通常の(週1) イベントウィンドウ 作成 まず、イベントウィンドウを作成してみます。 ただし、イベントウィンドウ には、AWSの仕様上、必要な最小時間を割り当てる必要があります。 例えば、以下のように、合計時間範囲が2時間の場合、作成に失敗します。 $ aws ec2 create-instance-event-window --name myEventWindowMonday2 --time-range StartWeekDay=monday,StartHour=0,EndWeekDay=monday,EndHour=2 --region ap-northeast-1 An error occurred (InvalidInstanceEventWindowTimeRange) when calling the CreateInstanceEventWindow operation: Time Ranges should have at-least 4 hours difference. 合計時間範囲は少なくとも4時間必要で、例えば以下のように指定する場合、作成は成功します。 $ aws ec2 create-instance-event-window --name myEventWindowMonday4 --time-range StartWeekDay=monday,StartHour=0,EndWeekDay=monday,EndHour=4 --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-11111111111111111", "TimeRanges": [ { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 4 } ], "Name": "myEventWindowMonday4", "State": "creating", "Tags": [] } } 複数期間に分割された イベントウィンドウ 作成 ただし、イベントウィンドウで確保する時間は、連続4時間でなくとも、最低2時間 x 複数回で、累計4時間を満たすことができれば良いようです。この方法で指定する場合、 --time-range オプションの Shorthand Syntax 指定では、複数回の指定ができません。あらかじめ、別ファイルに イベントウィンドウ の設定を記載しておく必要があります。例えば、以下のファイル "timerange.json" を用意します。 timerange.json [ { "StartWeekDay": "sunday", "StartHour": 0, "EndWeekDay": "sunday", "EndHour": 2 }, { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 2 } ] このファイルを指定して実行すると、複数期間に分割されたイベントウィンドウを作成することができました。 $ aws ec2 create-instance-event-window --name myEventWindowSundayMonday2 --time-range file://./timerange.json --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-22222222222222222", "TimeRanges": [ { "StartWeekDay": "sunday", "StartHour": 0, "EndWeekDay": "sunday", "EndHour": 2 }, { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 2 } ], "Name": "myEventWindowSundayMonday2", "State": "creating", "Tags": [] } } cron 指定での イベントウィンドウ 作成 また、 --time-range オプションの代わりに、--cron-expression オプションを利用することもできます。 $ aws ec2 create-instance-event-window --name myEventWindowMondayTuesday2 --cron-expression "* 0-2 * * 1,2" --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-33333333333333333", "Name": "myEventWindowMondayTuesday2", "CronExpression": "* 0-2 * * 1,2", "State": "creating", "Tags": [] } } やってみる : イベントウィンドウの変更、削除、表示 イベントウィンドウ 変更 modify-instance-event-window では、IDを指定することで、イベントウィンドウの設定を変更できます。変更では、イベントウィンドウの期間の設定だけでなく、名前も合わせて、一度に変更できるようです。 $ aws ec2 modify-instance-event-window --instance-event-window-id iew-33333333333333333 --name myEventWindowSundayMonday2 --cron-expression "* 0-2 * * 0,1" --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-33333333333333333", "Name": "myEventWindowSundayMonday2", "CronExpression": "* 0-2 * * 0,1", "AssociationTarget": { "InstanceIds": [], "Tags": [], "DedicatedHostIds": [] }, "State": "creating", "Tags": [] } } イベントウィンドウ 削除 delete-instance-event-window では、イベントウィンドウを削除します。 $ aws ec2 delete-instance-event-window --instance-event-window-id iew-22222222222222222 --region ap-northeast-1 { "InstanceEventWindowState": { "InstanceEventWindowId": "iew-22222222222222222", "State": "deleting" } } なお、delete-instance-event-window には、イベントウィンドウ が関連付けされている場合には削除しない --no-force-delete オプションと、関連付けされていても強制的に削除する --force-delete オプションがあります。 誤操作を防止するためには、 --no-force-delete を付けて実行するのが良いかもしれません。 イベントウィンドウ 表示 describe-instance-event-windows では、作成した イベントウィンドウ を表示します。 絞りこみなしで describe-instance-event-windows を実行することで、一覧を取得できます。 (なお、list--instance-event-windows といった API は、提供されていないようですね。) $ aws ec2 describe-instance-event-windows --region ap-northeast-1 { "InstanceEventWindows": [ { "InstanceEventWindowId": "iew-11111111111111111", "TimeRanges": [ { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 4 } ], "Name": "myEventWindowMonday4", "AssociationTarget": { "InstanceIds": [], "Tags": [], "DedicatedHostIds": [] }, "State": "active", "Tags": [] }, { "InstanceEventWindowId": "iew-33333333333333333", "Name": "myEventWindowMondayTuesday2", "CronExpression": "* 0-2 * * 1,2", "AssociationTarget": { "InstanceIds": [], "Tags": [], "DedicatedHostIds": [] }, "State": "active", "Tags": [] }, { "InstanceEventWindowId": "iew-22222222222222222", "TimeRanges": [ { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 2 }, { "StartWeekDay": "sunday", "StartHour": 0, "EndWeekDay": "sunday", "EndHour": 2 } ], "Name": "myEventWindowSundayMonday2", "AssociationTarget": { "InstanceIds": [], "Tags": [], "DedicatedHostIds": [] }, "State": "active", "Tags": [] } ] } やってみる : イベントウィンドウと EC2 の関連付け イベントウィンドウ のインスタンスIDとの関連付け associate-instance-event-window で EC2 と イベントウィンドウ を関連付けます。 $ aws ec2 associate-instance-event-window --instance-event-window-id iew-11111111111111111 --association-target InstanceIds=i-99999999999999999 --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-11111111111111111", "TimeRanges": [ { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 4 } ], "Name": "myEventWindowMonday4", "AssociationTarget": { "InstanceIds": [ "i-99999999999999999" ], "Tags": [], "DedicatedHostIds": [] }, "State": "creating" } } イベントウィンドウ の関連付け解除 disassociate-instance-event-window で EC2 との関連付けを解除します。 aws ec2 disassociate-instance-event-window --instance-event-window-id iew-11111111111111111 --association-target InstanceIds=i-99999999999999999 --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-11111111111111111", "TimeRanges": [ { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 4 } ], "Name": "myEventWindowMonday4", "AssociationTarget": { "InstanceIds": [], "Tags": [], "DedicatedHostIds": [] }, "State": "creating" } } なお、仮に、すべての関連付けを解除したい場合であっても、ターゲットを省略することはできず、--association-target の指定を怠った場合には、 CLI の実行は失敗するようです。 イベントウィンドウ のタグとの関連付け ターゲットの関連付けは、インスタンスIDではなく、タグを用いた指定も可能です。 aws ec2 associate-instance-event-window --instance-event-window-id iew-11111111111111111 --association-target InstanceTags="[{Key=EventWindow,Value=myEventWindowMonday4}]" --region ap-northeast-1 { "InstanceEventWindow": { "InstanceEventWindowId": "iew-11111111111111111", "TimeRanges": [ { "StartWeekDay": "monday", "StartHour": 0, "EndWeekDay": "monday", "EndHour": 4 } ], "Name": "myEventWindowMonday4", "AssociationTarget": { "InstanceIds": [], "Tags": [ { "Key": "EventWindow", "Value": "myEventWindowMonday4" } ], "DedicatedHostIds": [] }, "State": "creating" } } ただし、インスタンス ID と タグ の双方を同時に関連付けることはできません。 $ aws ec2 associate-instance-event-window --instance-event-window-id iew-11111111111111111 --association-target InstanceIds=i-99999999999999999,InstanceTags="[{Key=EventWindow,Value=myEventWindowMonday4}]" --region ap-northeast-1 An error occurred (InvalidParameterValue) when calling the AssociateInstanceEventWindow operation: Target Associations must be composed entirely of instance IDs or instance tags, but not both.2 まとめ AWS CLI で、EC2 のイベントウィンドウの操作を試してみました。 AWS 都合による EC2 の再起動イベントには、めったに出会うことはないような気もしますが、不意打ちされた時に慌てないように、事前に運用設計を関係者間で合意し、イベントウィンドウの設定をしておくと、いざという時に慌てずに済むかもしれませんね。

はじめに Lightsail 上の WordPress に Redis Object Cache を導入する。 Object Cache を導入すると、サイト表示が早くなるらしい。 環境 動作環境は以下の通り。 Linux ip-■■■-■■■-■■■ 4.19.0-17-cloud-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. ___ _ _ _ | _ |_) |_ _ _ __ _ _ __ (_) | _ \ | _| ' \/ _` | ' \| | |___/_|\__|_|_|\__,_|_|_|_|_| *** Welcome to the Bitnami WordPress 5.6.1-1 *** 手順 redis-server 導入 Lightsail のインスタンス画面から、ターミナルのアイコンをクリックして、Webuターミナルを起動する。 redis-server をインストールする。 sudo apt update -y sudo apt install redis-server -y redis-server を起動する。 sudo systemctl start redis-server Redis Object Cache プラグインの導入 プラグインの新規追加画面でRedis Object Cache を選択。 左下の【Enable Object Cache】ボタンをクリック。 【Status】が 【Connected】になったことを確認する。 参考サイト

CloudFormationを使って、MarketplaceのBitnamiのRedmineをデプロイしてみました。 Redmine自体の自動デプロイは幾つか記事にありますが、自分自身がAWSの経験が浅いことから少し苦労したので備忘の意味も込めて、こちらに残しておきたいと思います。 今回はAWS MarketPlaceのBitnamiのRedmine（ https://aws.amazon.com/marketplace/pp/prodview-urx6afmwf5y64 ）を使っていますので、Redmine自体の構築は不要になります。なので、細かい設定で迷うことなく構築できます。 ただ、http接続のままとしていますので社内専用か動作確認用など本番以外での使用を推奨します。 アーキテクチャー CloudFormationで設定している内容になります。至ってシンプルです。 前提条件 AWSアカウントを持っていること（権限はフルアクセスを想定）。 AWSでEC2用にアクセスするキーペアを持っていること。 概要 手順は至ってシンプルです。 1. CloudFormationのYAMLテンプレート(後述のredmine.yaml)を作成する。 2. CloudFormationでスタックを作成→デプロイする。 3. 数分経過したら、PublicDNSにアクセスする。 手順詳細 1.　以下のYAMLファイルを作成する redmine.yaml AWSTemplateFormatVersion: '2010-09-09' Parameters: KeyPair: Description: KeyPair Name Type: AWS::EC2::KeyPair::KeyName # Set Redmine imageid Mappings: StackConfig: EC2: ImageId: 'ami-0fe437920fe3d64e8' # Redmine Resources: # Create VPC RedmineVPC: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsHostnames: true EnableDnsSupport: true Tags: - Key: Name Value: RedmineVPC # Create InternetGateWay RedmineIGW: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: RedmineIGW # Attach IGW VPC AttachIGW: Type: AWS::EC2::VPCGatewayAttachment Properties: InternetGatewayId: !Ref RedmineIGW VpcId: !Ref RedmineVPC # create RouteTable RedminePublicRoute: Type: AWS::EC2::RouteTable Properties: VpcId: !Ref RedmineVPC Tags: - Key: Name Value: RedminePublicRoute # Set Routeing Route: Type: AWS::EC2::Route DependsOn: AttachIGW Properties: RouteTableId: !Ref RedminePublicRoute DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref RedmineIGW # Create PublicSubnet PublicSubnet: Type: AWS::EC2::Subnet Properties: AvailabilityZone: ap-northeast-1a CidrBlock: 10.0.1.0/24 VpcId: !Ref RedmineVPC Tags: - Key: Name Value: RedminePublicSubnet # Subnet Route connection PublicSubnetRouteTabelAssociation: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref RedminePublicRoute # Create security group # port22 80 443 RedmineSG: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref RedmineVPC GroupDescription: RedmineSG SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 0.0.0.0/0 - IpProtocol: tcp FromPort: 80 ToPort: 80 CidrIp: 0.0.0.0/0 - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 0.0.0.0/0 Tags: - Key: Name Value: RedmineSG # Create EC2 instance RedmineEC2: Type: AWS::EC2::Instance Properties: AvailabilityZone: ap-northeast-1a InstanceType: t2.micro ImageId: !FindInMap [ StackConfig, EC2, ImageId ] KeyName: !Ref KeyPair SubnetId: !Ref PublicSubnet SecurityGroupIds: - !GetAtt RedmineSG.GroupId Tags: - Key: Name Value: RedmineEnv # Create ElasticIP RedmineIP: Type: AWS::EC2::EIP Properties: InstanceId: !Ref RedmineEC2 # Output public DNS Outputs: PublicDNS: Description: EC2 Public DNS Value: !GetAtt RedmineEC2.PublicDnsName 2.　CloudFormationで[スタックの作成]-[新しいリソースの仕様(標準)]を選択する。 3.　[テンプレートの準備完了]-[テンプレートファイルのアップロード]を選択し、作成したredmine.yamlを選択して[次へ]を押す。 4.　[スタックの名前]に任意の名前、[KeyPair]に作成していたEC2のキーペアを選択して[次へ]を押す。 5.　スタックオプションの設定ではデフォルトのまま[次へ]を押す。 6.　レビューではデフォルトのまま[スタックの作成]を押す。 7.　約5分でデプロイが完了する。リソースタブで今回の構成で作成されるリソースを確認する。 作成されるリソース：　サブネット、EC2、インターネットゲートウェイ、ElasiticIP、セキュリティグループ、VPC 8.　出力タブに表示されているPublicDNSにアクセスする。リソースが作成されても、Redmineデプロイ自体に5分はかかる。 Redmine画面 Redmineログイン方法 RedmineのログインIDはuser、パスワードはEC2インスタンス画面から[アクション]-[モニタリングとトラブルシューティング]-[システムログを取得]から確認する 今回のパスワードはQ6nZFraKu2pfとなる。 RedmineEC2インスタンスへのSSHログイン RedmineEC2インスタンスへのSSHログインIDはbitnami、パスワード不要、SSHキーはスタックの詳細を設定で指定したKeyPairの秘密鍵となります。

全体像 1.EC2関連の準備 2.RDS関連の準備 3.EC2のpublicサブネットの中にapache, php, git, composer, その他Laravelの環境構築に必要なものをインストール 4.GitHubで管理の対象外となっている.envファイルの設定 5.php artisan migrateでテーブル作成 一番参考になった記事 https://qiita.com/nakm/items/0bcc6564538a0604b2ce EC2関連の準備 AWSの基本を コマンド

オリンピックで盛り上がって？ますが、東京オリンピック開催日にソリューションアーキテクト プロフェッショナル（SAP）を受験し、合格しました 試験を受けるまで 友人と一緒に取ろうとして半年以上前から言っていましたが、なかなか身が入らず先延ばしにしていました。 こうなったらもう先に試験を予約してしまおうということで、半ばノリで試験を予約しました。自分は締め切りが決まると火がつくタイプなんだなとつくづく思います。。 事前知識 現職だとあまりAWSを触る機会がなく、副業などで少し触る程度でした。 全くのゼロ知識ではないですが、ソリューションアーキテクト アソシエイトに合格（過去記事）したときの知識とほぼ変わらない状態でした。 学習方法 まず、アソシエイトに合格して1年半ほど経っていたので、まずは徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書の本を使って、アソシエイトの復習をしました。 そして下地をつけたところで、主に以下の本と、ブラックベルトを中心に学習しました。 AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 要点整理から攻略する『AWS認定 データベース-専門知識』 1つ目の対策本ですが、出版されているSAPの対策本としては、もはやこれしかないという本です。出題される問題でどういう視点で学習すべきかや、SAPを意識したケース問題、解説がついています。模擬試験もついており、それも含め3周しました。 この本を主軸に、理解できなかった場所や、理解が不十分だと思った場所を、ブラックベルトや公式のヘルプなどで学習を進めました。 2つ目の本は、AWS 認定 データベース – 専門知識の試験の対策本で、直接SAPの本ではないですが、AWSのDBマネージドサービスごとにその特徴や注意点が説明されており、SAPにも十分対策になると思い購入しました。 書き方が統一されていて、それぞれのサービスを比較して学習できるため、自分は頭に残りやすかったと思います。 また、オンプレからAWSへのDB移行方法などもうまくまとまっており、大変わかりやすかったです。 ちゃんと測ってないですが、試験まで3,4週間ほどということもあり、1日平均5時間ほど勉強をしていたので、トータル80時間~100時間ほどだと思います。 昼休憩もブラックベルトの動画や資料を見ながら取っていたので、大学受験生のような勉強をしてました。 いざ受験 7月の頭に、オンライン受験を予約して受けようとしていたのですが、当日トラブルが発生し、受験がキャンセルされました。。 オンライン受験では、専用のソフトウェアを入れて、試験担当から監視されつつ自宅で受験ができるのですが、受験当日こちらのカメラがなぜか試験担当に見えなかったようで、キャンセルになりました。（お金は戻ってきました） またトラブルが起きるのが嫌だったので、3週間後にテストセンターで受験するようにしました。 受験時の問題の解き方 試験が180分に対して、75問で、見直しの時間を30分ほど残したかったので、1問2分（1時間に30問）のペースで解いていきました。 しかし、問題が思っていたよりも難しく、予定よりオーバーしてしまい、見直しが20分ほどでした。 ただ、最後の方は、頭が疲弊しており、見直しもそこまで意味がなかったかもしれません。。 結果 受験者スコア: 864 でした。 試験結果は、100 から 1000 の間の値で、合格に必要な最低スコアは 750 なので、良くも悪くもない感じですかね。 振り返って 学習方法や、試験の受け方について、今回の合格結果をみつつ振り返ってみます。 試験の仕切り直しについて 最初の受験日に合わせてラストスパートを切っていたので、一度モチベーションが下がってしまいました。 3週間後に試験を設定しましたが、直前の1週間ほど再度対策本を読むぐらいになってしまいました。ただ、自分の感触的には、当初の試験で受けていてもあまり知識量と増えている感覚はなかったので、どのみち結果は変わらなかったかなと思います。 友達は先に合格していたので、変なプレッシャーはありましたが、合格できてよかったです。 本試験の感触 手応えとしては、まったくありませんでした。。最初は落ちたかもとか思ってましたが、合格画面が出たときは安堵しました。 かなり難しい試験とは聞いていましたが、本当になかなかに難しかったです。 学習方法について SAPの対策本のおかげで合格できたと思います。しかし、この本だけで行けたかというと、正直これだけで合格できる！とは言えないなと思いました。実際に学習したことがないサービスも出てきたりして、やはり網羅的に学習しておかないと怖いと思います。 SAP対策本の模擬試験を解くときに、本番を想定して練習していたので、時間感覚は持って望んだのはよかったかなと思います。3時間と長丁場なので、慣れてないと結構しんどいと思います。 また、すでにSAPを持っている友人に、わからないことを聞けたり、一緒に受ける友人と毎日朝会をして、わからないことを一緒に調べたりできたのはとてもよかったと思います。 自分だけだと偏った知識が着いたり、間違った理解をしていたかもしれません。 実務に使えるか いきなり「AWSでのシステム構築なんでもできます」とはならないとは思いますが、十分活かせそうだなと思います。 試験対策の学習の中で、ベストプラクティスに基づいたクラウドらしい設計についての知識が大いに着いたと思うし、ケース問題も実務に直面したときに考える上での参考になると思います。 まとめ 試験を通してAWSの設計やサービスにもより詳しくなれたし、SAPに合格できたことは、とても自信になったので、受けてよかったなと思います。

はじめに AWS（EC2）にデプロイする際、DB関連のエラーで躓いたため記録として残します。 DB関連にフォーカスしているので、それ以外のインストールの手順は省いています。 前提 ・今からmigrateします ・EC2インスタンス作成済み ・sshログインできる 条件 macOS: "11.2.3 Big Sur" php artisan -V # > Laravel Framework 6.20.30 php -v # > PHP 8.0.8 nginx -v # > nginx version: nginx/1.12.2 mysql -h エンドポイント -u マスターユーザー名 -p データベース名 Enter password: # > Server version: 8.0.25 git --version # > git version 2.32.0 1. php artisan migrateでエラー MySQLをインストール ssh sudo yum -y install mysql artisanコマンドが使えるディレクトリに移動してmigrate php artisan migrate すると以下のエラーが... SQLSTATE[HY000] [2002]　Connection timed out DBに接続をしようとしたけどできてない様子。 .envを確認して何回か修正したが、改善せず。 .envファイル 入れる値 DB_HOST エンドポイント DB_USERNAME マスターユーザー名 DB_PASSWORD マスターパスワード 解決 AWSのセキュリティグループ→インバウンドルールを確認すると、TypeがMySQLではなかったのが原因でした。 →MySQLに変更することで無事migrateすることができました。 php artisan migrate # migrate成功 Migration table created successfully. 念の為テーブル確認 ターミナル mysql -h エンドポイント -u マスターユーザー名 -p データベースの指定 -p の後は空白を開ける。空白を開けずに入力するとパスワードとなってしまいます。 以下が表示されれば接続成功。 ターミナル Welcome to the MariaDB monitor. Commands end with ; or \g. Your MySQL connection id is 174 Server version: 8.0.25 Source distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MySQL [(none)]> もし、-pを指定せずに接続しても以下のように指定することで見ることができます。 show databases;とすることで、全てのdatabaseが表示。 ターミナル MySQL [(none)]> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | lantern ← このdetabaseを確認したい | mysql | | performance_schema | | sys | +--------------------+ lanternというdetabaseを見たかったらuseで指定する。 ターミナル MySQL [(none)]> use lantern Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MySQL [lantern]> ← lanternに変更された 参考 このエラーを解決するにあたって以下のサイトを参考にさせて頂きました。 2. php artisan db:seedでエラー Class Faker\Factory Faker\Factoryのクラスがないよと言われる。 解決 Herokuで同じようなことが起こっている人たちがいましたが、AWSでも同じようにすると解決できました。 結論から言うと、以下のようにfakerphp/fakerをrequire-devからrequireへ移動しました。 composer.json "require": { "php": "^7.2.5|^8.0", "doctrine/dbal": "^3.1", "fideloper/proxy": "^4.4", "intervention/image": "2.5.1", "laravel/framework": "^6.20.26", "laravel/tinker": "^2.5", + "fakerphp/faker": "^1.9.1" }, "require-dev": { "barryvdh/laravel-debugbar": "^3.6", "facade/ignition": "^1.16.15", "laravel/ui": "^1.0", "mockery/mockery": "^1.0", "nunomaduro/collision": "^3.0", "phpunit/phpunit": "^8.5.8|^9.3.3" - "fakerphp/faker": "^1.9.1" }, デプロイの際、パッケージのインストールで以下のように記述しました。 composer install --no-dev --prefer-dist --no-devとすることで、「開発環境のみ必要で本番環境で必要ないパッケージはインストールしない」とできます。 具体的には、phpunitやdebugbarなどは本番環境には必要ないためインストールされないようにしています。 「開発環境のみ」というのはrequire-devの部分です。 上記のコマンドを実行するとrequire-devで書かれているものはインストールされません。 修正後、gitにpushし本番環境でもcomposerをアップデートして反映させます。 composer update この後にもう一度php artisan db:seedをすると無事実行されました。 php artisan db:seed Database seeding completed successfully. 参考 このエラーを解決するにあたって以下のサイトを参考にさせて頂きました。 おわり この他にも、ディレクトリの記述ミスで実行できなかったのもあり、これを機にディレクトリをしっかり意識するようになりました。 初歩的なミスばかりですが、おかげでデプロイの概要が少しずつ理解できてきたかなと感じます！ このまま自動デプロイ目指してやっていきます！ 参考

はじめに Amazon Aurora記事第二弾。 前回に続き、今回は作成したAuroraクラスタにRDSプロキシを追加する。 RDSプロキシは、接続負荷を下げるためにLambdaからAuroraに接続するときは必須になる。一方で、常時接続するようなコネクションプールを持ったコンテナアプリケーションの場合は不要でありつつ、AutoScalingした際の管理の手間を省くには便利な機能だったりする(接続のオーバーヘッドがあるため、大量の処理を捌くようなワークロードには使いにくいと思われる)。 今回の記事では、前回記事で作ったTerraformのHCLに付け加える前提であるため、実際に触ってみる場合はまずは前回記事から読んでいただきたい。 Secrets Manager いきなりだが、RDSプロキシのユーザの接続管理にはSecrets Managerを使う。 これがないと構築ができないので、まずは作成しておこう。 resource "aws_secretsmanager_secret" "dbproxy" { name = local.secret_manager_name recovery_window_in_days = 0 } resource "aws_secretsmanager_secret_version" "dbproxy" { secret_id = aws_secretsmanager_secret.dbproxy.id secret_string = jsonencode({ username : aws_rds_cluster.example.master_username password : aws_rds_cluster.example.master_password engine : aws_rds_cluster.example.engine host : aws_rds_cluster.example.endpoint port : aws_rds_cluster.example.port dbInstanceIdentifier : aws_rds_cluster.example.id }) } recovery_window_in_days については、設定しなくても良い(削除時に何日間残しておくかという設定)。 ただし、検証環境のように何度か作っては消して、とやるケースでは、設定していないと、再構築時にシークレットの名前が重複してエラーになってしまう。 もし、消せなくなってしまった場合は、このページを参考にしつつ削除しておこう。デフォルトだと、削除予約中のシークレットはマネージメントコンソールでも参照できないので、ちょっと戸惑うことになる。 IAM さらに、RDSプロキシがSecrets ManagerにアクセスするためにIAMの設定が必要になる。 以下のような感じで設定しておこう。resourcesはもう少し真面目に設定しておいた方が良いかもしれない。 resource "aws_iam_role" "dbproxy" { name = local.iam_dbproxy_role_name assume_role_policy = data.aws_iam_policy_document.dbproxy_assume.json } data "aws_iam_policy_document" "dbproxy_assume" { statement { effect = "Allow" actions = [ "sts:AssumeRole", ] principals { type = "Service" identifiers = [ "rds.amazonaws.com", ] } } } resource "aws_iam_role_policy" "dbproxy" { name = local.iam_dbproxy_policy_name role = aws_iam_role.dbproxy.id policy = data.aws_iam_policy_document.dbproxy_custom.json } data "aws_iam_policy_document" "dbproxy_custom" { statement { effect = "Allow" actions = [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret", "secretsmanager:ListSecretVersionIds" ] resources = [ "arn:aws:secretsmanager:*:*:*", ] } statement { effect = "Allow" actions = [ "kms:Decrypt", ] resources = [ "*", ] } } Aurora RDSプロキシの基本設定 さて、あとはRDSプロキシの設定だけだ。 リソースは以下のものを使う。 aws_db_proxy aws_db_proxy_default_target_group aws_db_proxy_target aws_db_proxy のrole_arnには、↑で作成したロールのARNを設定しておこう。 また、authのsecret_arnには、↑で作成したSecrets ManagerのARNを設定する。 vpc_security_group_idsはMySQLであればインバウンドの3306ポートが空いていれば良い。 debug_loggingは、いったんtrueで構築するが、接続テストまで終わったらfalseにしよう。設定が間違っていた時等、CloudWatch Logsでエラー状況が確認できるので便利だ。このCloudWatch Logsはterraform destroyで自動削除はされない上に、デフォルトでは失効しない設定なので注意が必要だ。 ちなみに、Terraformの公式ドキュメントの通りに設定すると、MySQLのクライアントでSQL実行時にUnknown Errorが発生する。どうやら、init_queryとsession_pinning_filtersが悪さをするようだ。ここは、ちゃんと理解をした上で適宜必要に応じて設定をしていこう。 resource "aws_db_proxy" "example" { depends_on = [ aws_rds_cluster_instance.example, ] name = local.rds_proxy_name debug_logging = true engine_family = "MYSQL" idle_client_timeout = 60 require_tls = false role_arn = aws_iam_role.dbproxy.arn vpc_security_group_ids = [aws_security_group.aurora.id] vpc_subnet_ids = data.aws_subnet_ids.my_vpc.ids auth { auth_scheme = "SECRETS" iam_auth = "DISABLED" secret_arn = aws_secretsmanager_secret.dbproxy.arn } } resource "aws_db_proxy_default_target_group" "example" { db_proxy_name = aws_db_proxy.example.name connection_pool_config { connection_borrow_timeout = 120 max_connections_percent = 100 max_idle_connections_percent = 50 } } resource "aws_db_proxy_target" "example" { db_proxy_name = aws_db_proxy.example.name db_cluster_identifier = aws_rds_cluster.example.id target_group_name = aws_db_proxy_default_target_group.example.name } これで、RDSプロキシが設定され接続可能になる。 RDSプロキシはVPC内からしかアクセスができないため、接続確認はEC2等を立てて確認しよう。 ReadOnlyなエンドポイントの追加 さて、作成したプロキシエンドポイントをマネージメントコンソールで確認してみると、以下の通り、Writerインスタンスに対してもプロキシを作ってしまっていることが分かる。 あくまでも参照処理のみさせたい場合、これではよろしくないので、自分でエンドポイントを作成しよう。 resource "aws_db_proxy_endpoint" "example" { db_proxy_name = aws_db_proxy.example.name db_proxy_endpoint_name = "${local.rds_proxy_name}-ro" vpc_security_group_ids = [aws_security_group.aurora.id] vpc_subnet_ids = data.aws_subnet_ids.my_vpc.ids target_role = "READ_ONLY" } これまたTerraform公式ドキュメントの罠なのだが、例にはvpc_security_group_idsが設定されていないものの、これを設定していないと通信ができずにエラーになる。ちゃんと3306ポートを通しておくようにしよう。 試しに接続してCREATE TABLEしてみると… MySQL [COMPANY]> CREATE TABLE EMPLOYEE ( -> id CHAR(5) PRIMARY KEY, -> name CHAR(20) NOT NULL, -> age INTEGER -> ); ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement ちゃんとエラーになってくれた。 これで、ReadOnlyなプロキシエンドポイントから安全に接続できるようになったぞ！

※記事について著作権等で問題がありましたら、お手数ですがコメントいただけると幸いです。早急に修正か、必要に応じて記事を削除いたします。 AWS初心者による、SAA取得に向けた学習の記録⑤ の続きです。 関連記事はこちらからどうぞ。 AWS初心者による、SAA取得に向けた学習の記録① AWS初心者による、SAA取得に向けた学習の記録② AWS初心者による、SAA取得に向けた学習の記録③ AWS初心者による、SAA取得に向けた学習の記録④ AWS初心者による、SAA取得に向けた学習の記録⑤ AWS初心者による、SAA取得に向けた学習の記録⑥ ※参考書籍 AWS認定資格試験テキスト AWS認定ソリューションアーキテクト・アソシエイト 改訂版第2段 今回は RDS Amazon Aurora Redshift DynamoDB ElastiCache についての内容となります。 RDS（Relational Database Service） RDS は、AWSが提供するマネージドRDBサービス。 機能概要 MySQLやPostgreSQL、Microsoft SQL Serverなどの様々なDBエンジンから選択可能 データ保存のストレージにはEBSを使用し、利用可能なストレージタイプは以下の三種類 汎用SSD プロビジョンドIOPS SSD マグネティック DBインスタンス作成時のオプションでマルチAZ構成にすることができるが、以下の注意点がある 書き込み速度が若干遅くなる フェイルオーバーに時間がかかる リードレプリカと呼ばれる、通常のRDSとは別に参照用のDBインスタンスを作成する機能がある これによりマスターの負荷を軽減し、読み込みの多いDBリソースのスケールアウトが実現可能 マスターとリードレプリカの同期は非同期レプリケーション方式のため、リードレプリカの参照タイミングによっては最新のマスタが反映されていない可能性もある インスタンスごとにセキュリティグループの指定が可能 暗号化オプションを有効にすることで、データストレージやスナップショット、ログといったRDS関連のデータの暗号化が可能 既に存在するデータに対しては取得したスナップショットから暗号化コピーを作成し、そこからDBインスタンスを作成することで可能 RDS作成時に接続用エンドポイント（FQDN）が1つ作成される バックアップ 自動バックアップ：バックアップウィンドウと保持期間を指定して一日に一回DBスナップショットを取得する機能 保持期間は最大35日 復旧にはスナップショットから新規RDSを作成する（稼働中のRDSにバックアップデータを戻すことは不可） 手動スナップショット：任意のタイミングでDBスナップショットの取得が可能 上限はリージョンあたり100個 手動でスナップショットをとる場合、DBをマスター/スタンバイの状態にしておくとI/O瞬断が発生しない リストア：作成したスナップショットを選択し、新規RDSを作成する Amazon Aurora Amazon Aurora は、AWSが独自に開発したRDSのDBエンジンで、クラウドサービスを活かしたアーキテクチャとなっている。 構成要素 DBインスタンス作成時にDBクラスタが作成される DBクラスタは以下から構成される 一つ以上のDBインスタンス 各DBインスタンスから参照するストレージ（クラスタボリューム） ストレージはSSDベースのクラスタボリューム クラスタボリュームは単一リージョン内の3つのAZに各2つずつ構成され、自動で同期される 他のRDSのようなマルチAZ構成オプションはないが、クラスタ内に参照専用のレプリカインスタンスの作成が可能 プライマリインスタンスの障害発生時に、レプリカインスタンスがプライマリに昇格することでフェイルオーバーを実現 画像引用元：AWS再入門ブログリレー Amazon Aurora 編 Redshift Redshift は、AWSが提供するデータウェアハウス向けのDBサービス。 構成要素 特徴は複数ノードによる分散並列処理 1つのRedshiftを構成するノードの集まりをRedshiftクラスタという クラスタは1つのリーダーノードと複数のコンピュートノードから構成される 複数のコンピュートノードを跨がずに処理を行う構成が望ましい リーダーノード SQLクライアントやBIツールの実行クエリによって、クエリの解析や実行プランの作成を行う また、各コンピュートノードの処理結果を返却するレスポンス処理も行う リーダーノードはクラスタに1台のみ コンピュートノード リーダーノードからの実行クエリを処理する ストレージとセットで構成されており、コンピュートノードの追加によってCPUやメモリなどのリソースの増加が可能 ノードスライス Redshiftが分散並列処理を行う最小単位 コンピュートノードのリソースをさらに分割したスライスという単位で構成される スライス数はコンピュートノードのインスタンスタイプによって異なる 列指向型（カラムナ）データベースで、集計処理に使用されるデータを列単位でまとめて管理することでデータ取得を効率化する ゾーンマップ Redshiftではブロック単位でデータが格納されており、そのブロックに格納されているデータの最小値と最大値をメモリに保存する仕組みのことを ゾーンマップと呼ぶ。 これを活用することでデータ検索処理の高速化を実現する。 1ブロックの容量は1MB。 MPPとシェアードナッシング MPP（Massively Parallel Processing） は一回の集計処理を複数のノードに分散して実行する仕組み。 これによりノードの追加をするだけで処理のパフォーマンスを向上させることが可能。 シェアードナッシング は、複数のノードがディスクを共有せずにノードとディスクがセットで拡張される仕組み。 複数ノードが同一のディスクを共有することで発生するI/O性能の低下を防ぐことが可能。 これらの仕組みによって柔軟な拡張性が実現されている。 Redshift Spectrum Redshift Spectrum は、S3のデータを外部テーブルとして定義できるようにし、Redshiftにデータを取り込まずにクエリの実行を可能にするサービス。 RedshiftのデータとS3のデータを組み合わせたSQLの実行が可能なため、データの使用目的に応じてストレージを使い分けることができる。 DynamoDB DynamoDB は、AWSが提供するKey-Value型のマネージドNoSQLデータベースサービス。 テーブルやインデックスの作成時に、読み取り・書き込みに必要なスループットを指定してリソースを確保することにより、安定した性能を提供する仕組みとなっている。 機能概要 単一障害点を持たない構成のため、障害対応やメンテナンス時の運用を考える必要がない データが自動で3つのAZに保存される テーブルやインデックスの作成時に指定するスループットキャパシティはいつでもダウンタイムなく変更可能 Read Capacity Unit(RCU)：読み取りのスループットキャパシティを指定する指標 Write Capacity Unit(WCU)：書き込みのスループットキャパシティを指定する指標 それぞれ増加回数に制限はないが、減少回数は1日9回まで また、負荷の状況に応じて自動でスケーリングすることも可能 Key-Value型のDBのため、データ項目はキーとなる属性とその他の情報で構成される プライマリキー：データを一意に特定するための属性で、「パーティションキー」単独と「パーティションキー＋ソートキー」で構成される二種類がある。パーティションキーだけで特定できない場合はソートキーと組み合わせてプライマリキーを構成する。プライマリキーはインデックスとしても利用され、プライマリキーのみでは高速化が難しい場合に「セカンダリインデックス」を作成する。 セカンダリインデックス ローカルセカンダリインデックス：プライマリキーはテーブルで指定したパーティションキーと同一で、別の属性をソートキーとして作成するインデックスのこと。元テーブルと同一のパーティション内で検索が完結する。 グローバルセカンダリインデックス：プライマリキーとは異なる属性を使用して作成するインデックスのこと。テーブルとは別のキャパシティユニットでスループットを指定。 有効期限を設定したデータを自動で削除することが可能 DynamoDB Streamsという機能で、直近24時間の変更履歴を保存することが可能 DynamoDB Accelerator(DAX)で、DynamoDBの前段にキャッシュクラスタを構成することが可能 セカンダリインデックスは本来のKey-Value型のDBの使い方ではないため、RDBへの変更を検討する必要もある。 ElastiCache ElastiCache は、AWSが提供するインメモリ型データベースサービスで、MemcachedとRedisの二種類がある。 Memcached Key-Valueストア型インメモリデータベースのデファクトスタンダードとして広く使用されるエンジン。 以下の用途で使用。 シンプルなキャッシュシステム データが消失してもシステムの動作に大きな影響を与えない 必要なキャッシュリソースの増減が頻繁にあり、スケールアウト/スケールインをする必要がある Memcachedクラスタは、最大20のElastiCacheインスタンスで構成され、保存されるデータは複数のインスタンスに分散される。 エンドポイント クラスタの作成時、二種類のアクセス用エンドポイントが作成される。 ノードエンドポイント：各ノードに個別にアクセスするためのエンドポイント。 設定エンドポイント：クラスタ全体に割り当てられるエンドポイント。クラスタ内のノード増減を管理し、クラスタの構成情報を自動で更新する スケーリング スケールアウト、スケールイン、スケールアップ、スケールダウンの4つからリソースの調整が可能であるが、以下の2点に注意する必要がある。 スケールアウトとスケールイン ノード数の増減時に、正しいノードにデータが再度マッピングされるまでの間にキャッシュミスが増加することがある スケールアップとスケールダウン これらを行う際には新規のクラスタを作成する必要がある。 Redis Memcachedと同様にKVS型インメモリデータベースで、Memcachedより多くのデータが扱えるのと、キャッシュ用途だけではなくメッセージブローカーやキューを構成する要素としても利用可能。 以下の用途で使用。 様々なデータ型を扱いたい キーストアに永続性を持たせる 障害発生時、自動でフェイルオーバーしたりバックアップ/リストアなどの可用性が必要 クラスタモードの有効/無効に応じて冗長化の構成が変わるが、どちらの場合もマルチAZ構成にすることが可能なため、マスターインスタンスの障害発生時にはスタンバイインスタンスがマスターに昇格する。 クラスタモード無効 キャッシュデータは1つのElastiCacheインスタンスに保存される。 同じデータを持つリードレプリカを5つまで作成可能 これらのまとまりをシャードと呼ぶ クラスタモード有効 最大500のシャードにデータを分割して保存可能 リードレプリカは1つのシャードに対して最大5つ データ分散によりデータの読み書きの負荷分散構成の実現が可能 エンドポイント クラスタの作成時、三種類のアクセス用エンドポイントが作成される。 ノードエンドポイント：各ノードに個別にアクセスするためのエンドポイント。クラスタ構成がどちらの場合でも使用可能 プライマリエンドポイント：書き込み処理用のElastiCacheインスタンスにアクセスするためのエンドポイント。クラスタ構成が無効の場合に使用 設定エンドポイント：クラスタモード有効時、ElastiCacheクラスタに対する全ての操作が可能 CPU使用率 Redisはシングルスレッドのため、4コアのインスタンスタイプを使用してもCPU使用率はそれぞれに分散された25%が最大値となる。 データ暗号化 RedisクライアントとElastiCache間の通信、ElastiCache内に保存するデータの暗号化をサポート。 データの暗号化はRedis版のElastiCacheにのみ対応。 終わりに 最後まで読んでいただきありがとうございました。 関連記事はこちらからどうぞ。 AWS初心者による、SAA取得に向けた学習の記録① AWS初心者による、SAA取得に向けた学習の記録② AWS初心者による、SAA取得に向けた学習の記録③ AWS初心者による、SAA取得に向けた学習の記録④ AWS初心者による、SAA取得に向けた学習の記録⑤ AWS初心者による、SAA取得に向けた学習の記録⑥ ※参考書籍 AWS認定資格試験テキスト AWS認定ソリューションアーキテクト・アソシエイト 改訂版第2段

初めに 以下のチュートリアルをやってみました。これまで API Gateway の基本的な部分が分からなかったのですが、カスタム統合のチュートリアルに着手することで理解できました。マッピングテンプレートやクエリ文字列パラメータ、リソース・メソッド、API のデプロイについて理解が深まりました。 Lambda プロキシ統合とは API Gateway の API 統合の種類の一つです。バックエンドが Lambda であり、 統合リクエスト・統合レスポンスの設定が不要な統合タイプです。 統合エンドポイントのタイプ 使用可能なAPI統合タイプ Lambda関数 Lambdaプロキシ統合 Lambdaカスタム統合 HTTPエンドポイント HTTPプロキシ統合 HTTPカスタム統合 AWSサービスアクション 非プロキシタイプの AWS 統合のみ Lambda 関数を作成する ナビゲーションペインから「関数」を選択します。 「関数の作成」をクリックします。 関数の名前、ランタイム、ロールを設定します。ポリシーテンプレートは空白にしておきます。 関数のコードに以下をペーストします。 'use strict'; console.log('Loading hello world function'); exports.handler = async (event) => { let name = "you"; let city = 'World'; let time = 'day'; let day = ''; let responseCode = 200; console.log("request: " + JSON.stringify(event)); if (event.queryStringParameters && event.queryStringParameters.name) { console.log("Received name: " + event.queryStringParameters.name); name = event.queryStringParameters.name; } if (event.queryStringParameters && event.queryStringParameters.city) { console.log("Received city: " + event.queryStringParameters.city); city = event.queryStringParameters.city; } if (event.headers && event.headers['day']) { console.log("Received day: " + event.headers.day); day = event.headers.day; } if (event.body) { let body = JSON.parse(event.body) if (body.time) time = body.time; } let greeting = `Good ${time}, ${name} of ${city}.`; if (day) greeting += ` Happy ${day}!`; let responseBody = { message: greeting, input: event }; // The output from a Lambda proxy integration must be // in the following JSON object. The 'headers' property // is for custom response headers in addition to standard // ones. The 'body' property must be a JSON string. For // base64-encoded payload, you must also set the 'isBase64Encoded' // property to 'true'. let response = { statusCode: responseCode, headers: { "x-custom-header" : "my custom header value" }, body: JSON.stringify(responseBody) }; console.log("response: " + JSON.stringify(response)) return response; }; 「Deploy」をクリックします。 「Changes deployed」が表示されたことを確認します。 REST API を作成する 「APIを作成」をクリックします。 REST API の「構築」をクリックします。 以下のようにプロトコルを設定します。 「アクション」のドロップダウンから「リソースの作成」をクリックします。 リソース名を入力し、「リソースの作成」をクリックします。 作成したリソースを選択した状態で「メソッドの作成」をクリックします。 「ANY」を選択し、横のチェックマークをクリックします。 以下のように設定します。 権限を追加するかどうか聞かれるので「OK」をクリックします。 「API のデプロイ」をクリックします。 以下の URL はリクエストに使用します。 リクエスト PS C:\tutorial> curl.exe -v -X POST "https://API_Gateway_ID.execute-api.ap-northeast-1.amazonaws.com/test/helloworld?name=John&city=Seattle" -H "content-type: application/json" -H "day: Thursday" -d '{ "time": "evening" }' Lambda が受け取ったイベント API Gateway は上記のリクエストを Lambda に渡すために次のような JSON フォーマットに変換します。 { "resource": "/helloworld", "path": "/helloworld", "httpMethod": "GET", "headers": { "Accept": "*/*", "content-type": "application/json", "day": "Thursday", "Host": "API_Gateway_ID.execute-api.ap-northeast-1.amazonaws.com", "User-Agent": "curl/7.55.1", "X-Amzn-Trace-Id": "Root=1-60fbfb9a-70429bfb1ef089820112571c", "X-Forwarded-For": "11.22.333.44", "X-Forwarded-Port": "443", "X-Forwarded-Proto": "https" }, "multiValueHeaders": { "Accept": [ "*/*" ], "content-type": [ "application/json" ], "day": [ "Thursday" ], "Host": [ "API_Gateway_ID.execute-api.ap-northeast-1.amazonaws.com" ], "User-Agent": [ "curl/7.55.1" ], "X-Amzn-Trace-Id": [ "Root=1-60fbfb9a-70429bfb1ef089820112571c" ], "X-Forwarded-For": [ "11.22.333.44" ], "X-Forwarded-Port": [ "443" ], "X-Forwarded-Proto": [ "https" ] }, "queryStringParameters": { "city": "Seattle", "name": "John" }, "multiValueQueryStringParameters": { "city": [ "Seattle" ], "name": [ "John" ] }, "pathParameters": null, "stageVariables": null, "requestContext": { "resourceId": "il7kor", "resourcePath": "/helloworld", "httpMethod": "GET", "extendedRequestId": "C-RANGv6tjMFtiA=", "requestTime": "24/Jul/2021:11:38:02 +0000", "path": "/test/helloworld", "accountId": "123456789012", "protocol": "HTTP/1.1", "stage": "test", "domainPrefix": "API_Gateway_ID", "requestTimeEpoch": 1627126682797, "requestId": "7a6335b9-554b-43a7-a228-3a9fb9f10a73", "identity": { "cognitoIdentityPoolId": null, "accountId": null, "cognitoIdentityId": null, "caller": null, "sourceIp": "11.22.333.44", "principalOrgId": null, "accessKey": null, "cognitoAuthenticationType": null, "cognitoAuthenticationProvider": null, "userArn": null, "userAgent": "curl/7.55.1", "user": null }, "domainName": "API_Gateway_ID.execute-api.ap-northeast-1.amazonaws.com", "apiId": "API_Gateway_ID" }, "body": null, "isBase64Encoded": false } レスポンス { "message":"Good day,John of Seattle. Happy Thursday!", "input":{ "resource":"/helloworld", "path":"/helloworld", 「CloudWatch のログを表示」をクリックすれば、Lambda 関数のログを確認できます。 Lambda 非プロキシ統合（カスタム統合）とは メソッドリクエストをどのように統合リクエストにマッピングするか、統合レスポンスをどのようにメソッドレスポンスにマッピングするかを設定する Lambda 統合です。 Lambda 関数のコードを置き換える 以下のコードで最初に作成したコードを置き換えます。 'use strict'; var days = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday']; var times = ['morning', 'afternoon', 'evening', 'night', 'day']; console.log('Loading function'); exports.handler = function(event, context, callback) { // Parse the input for the name, city, time and day property values let name = event.name === undefined ? 'you' : event.name; let city = event.city === undefined ? 'World' : event.city; let time = times.indexOf(event.time)<0 ? 'day' : event.time; let day = days.indexOf(event.day)<0 ? null : event.day; // Generate a greeting let greeting = 'Good ' + time + ', ' + name + ' of ' + city + '. '; if (day) greeting += 'Happy ' + day + '!'; // Log the greeting to CloudWatch console.log('Hello: ', greeting); // Return a greeting to the caller callback(null, { "greeting": greeting }); }; REST API を作成する / の下に city というリソースを作成します。リソースパスは波括弧を付けて {city} とします。「API Gateway CORS を有効にする」にチェックを入れます。 メソッドは「ANY」を選択し、Lambda 関数を指定します。プロキシ統合にチェックを入れずにを「保存」をクリックします。 メソッドリクエストを編集します。 「クエリ文字の追加」をクリックします。 以下のように設定します。 ヘッダーを以下のように追加します。 「モデル」を選択します。 「作成」をクリックします。 モデル名を入力し、コンテントタイプに「application/json」と入力します。モデルのスキーマは以下を貼り付けます。 { "$schema": "http://json-schema.org/draft-04/schema#", "title": "GetStartedLambdaIntegrationInputModel", "type": "object", "properties": { "callerName": { "type": "string" } } } リクエスト本文に作成したモデルを指定します。 統合リクエストを編集します。 「マッピングテンプレートの追加」をクリックします。「application/json」と入力し、チェックマークをクリックします。 「はい、この統合を保護します」をクリックします。 以下のように設定されていることを確認します。 テンプレートの生成に作成したモデルを選択します。本文は以下で置き換えます。 #set($inputRoot = $input.path('$')) { "city": "$input.params('city')", "time": "$input.params('time')", "day": "$input.params('day')", "name": "$inputRoot.callerName" } テストの稲妻マークをクリックします。 メソッドは「POST」、パスは「Seattle」、クエリ文字列は「time=morning」、ヘッダーは「day:Wednesday」、リクエスト本文は「{ "callerName":"John" }」を入力します。 ステータスが 200 となっていれば成功です。 API のデプロイをします。ステージ変数は「custom」と入力します。 以下の URL にリクエストを送ります。 リクエスト PS C:\tutorial> curl.exe -v -X POST "https://API_Gateway_ID.execute-api.ap-northeast-1.amazonaws.com/custom/Seattle?time=evening" -H "content-type: application/json" -H "day: Thursday" -H "x-amz-docs-region: ap-northeast-1" -d '{"callerName": "John"}' /Seattle ・・・ リソース。これが city: 'Seattle' にマッピングされる。 ?time=evening ・・・ クエリ文字列パラメータ。これが time: 'evening' にマッピングされる。 day: Thursday ・・・ HTTP リクエストヘッダー。これが day: 'Thursday' にマッピングされる。 {"callerName": "John"} ・・・ リクエスト本文。これが name: 'John' にマッピングされる。 上記のパラメータは以下の設定に対応しています。 Lambda が受け取ったイベント { city: 'Seattle', time: 'evening', day: 'Thursday', name: 'John' } 上記のイベントは統合リクエストのマッピングテンプレートによって作成されます。 レスポンス {"greeting":"Good evening, John of Seattle. Happy Thursday!"} 参考記事

はじめに AWSでサービス監視を実装して、サービスの正常性を監視してみました。 前提条件 EC2インスタンスが構築されていること（今回はAmazon Linux2を使用します） パブリックサブネットへ接続するインターネットゲートウェイはアタッチ済みであること サービスの正常性を確認する対象はApache(httpd)とします CloudWatchエージェントが導入済みであること。 （入れていない場合は、導入方法も別で記載していますのでご確認ください） 【導入手順】 AWSでCloudWatchエージェントを入れてみた 構成図 今回は「httpdを監視して、プロセス数が0になったらEC2インスタンスを再起動する」という実装にします。 大まかな流れとしては 1. サービス監視用のCloudWatch Agentの設定ファイルを作成する 2. 設定ファイルをSSMで反映する 3. CloudWatch上でhttpdのプロセスが取れているか確認する 4. httpdプロセス用のCloudWatchアラームを作成する 5. Apache停止を行ってアラームが発砲されているか確認する 6. EC2インスタンスが再起動していることを確認する 実際にやってみた サービス監視用のCloudWatchエージェントの設定ファイルを作成 特定のプロセスを監視するための設定ファイルを作成します。設定ファイルはSSMのパラメータストアに格納します。 SSMからパラメータストアへ移動しパラメータの作成をクリックします。 パラメータの詳細は以下の通りで記述していきます。 名前：後で使用するので判別しやすい名前にしておくと良いです 説明：説明文を入力する 利用枠：標準 タイプ：文字列 データ型：text 値：{ "metrics": { "metrics_collected": { "procstat": [ { "exe": "httpd", "measurement": [ "pid_count" ], "metrics_collection_interval": 60 } ] } } } 値について簡単に説明します。 ・exe ：プロセス名を記述します。今回はhttpdを監視するので"httpd"を記述する Linuxサーバで設定する"exe"セクションでは、指定した文字列に対して全て正規表現で読み取りますので、ワイルドカードを使用して複数のプロセスを指定することも可能です。 ・pid_count ：プロセスが起動している数。今回はhttpdのプロセス数を読み取ります。 ・metrics_collection_interval ：対象のメトリクスを収集する間隔を指定します。httpdプロセスを収集する間隔はデフォルトの"60秒"としておきます。（ちなみにこのセクションは省略可能です） ※exeの設定の仕方について、公式ドキュメントに記載されています。 exe以外の方法もありますので、要求内容に合わせて設定ください。 procstat プラグインでプロセスメトリクスを収集する 設定ファイルを反映する 設定したファイルをCloudWatchエージェントに反映していきます。 SSMから"Run Command"を選択してコマンドパラメータは以下の通り入力します。 ・Action：Configure(Append)　　既に反映されているパラメータが存在するのでそれに追記します ・Mode：ec3 ・Optional Configuration Source：ssm ・Optional Configuration Location：httpd-proc-collector　　先ほど作成した設定ファイル名を入力 ・Optional Open Telemetry Collector Configuration Source：ssm ・Optional Open Telemetry Collector Configuration Location：未記入 ・Optional Restart：yes ターゲットは対象のインスタンスを指定します。 その他はデフォルトで実行すると実行結果が出力されます。 ターゲットと出力のインスタンスIDをクリックして中身を確認しましょう。 「Output」と「Error]でログを確認します。 「Output」 ****** processing amazon-cloudwatch-agent ****** /opt/aws/amazon-cloudwatch-agent/bin/config-downloader --output-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --download-source ssm:httpd-proc-collector --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config append Region: ap-northeast-1 credsConfig: map[] Successfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/ssm_httpd-proc-collector.tmp Start configuration validation... /opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --input-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config append /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json does not exist or cannot read. Skipping it. Valid Json input schema. I! Detecting run_as_user... No csm configuration found. No log configuration found. Configuration validation first phase succeeded /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml Configuration validation second phase succeeded Configuration validation succeeded 「Error」 2021/07/24 14:52:44 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json ... 2021/07/24 14:52:44 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/ssm_AmazonCloudWatch-linux ... 2021/07/24 14:52:44 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/ssm_httpd-proc-collector.tmp ... Redirecting to /bin/systemctl stop amazon-cloudwatch-agent.service Redirecting to /bin/systemctl restart amazon-cloudwatch-agent.service サービスを再起動したログみたいなのでエラー出力ではありませんね。 設定ファイルの読み込みも成功しているのでこのまま先へ進めます。 CloudWatchのメトリクスを確認 CloudWatch画面に移動して「メトリクス」をみてみましょう。 「CWAgent」から「ImageId,InstanceId,InstanceType,exe,pid_finder」というディメンションがありその中に対象のメトリクスが存在しています。 対象のメトリクスが取れていますね。 プロセスが7つあるみたいです。念のためサーバへログインして確認してみましょう。 [ec2-user@ip-10-0-1-10 ~]$ ps -ef | grep httpd root 2798 1 0 00:30 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 2829 2798 0 00:30 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 2830 2798 0 00:30 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 2831 2798 0 00:30 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 2832 2798 0 00:30 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 2833 2798 0 00:30 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND apache 3184 2798 0 00:33 ? 00:00:00 /usr/sbin/httpd -DFOREGROUND ec2-user 3368 3343 0 00:43 pts/1 00:00:00 grep --color=auto httpd [ec2-user@ip-10-0-1-10 ~]$ 最下行の"ec2-user"が起動しているもの以外がhttpdプロセスで合計7つで合っていますね。 アラームを発泡させてみる まずアラームを作成する CloudWatchの「アラーム」へ移動し、「メトリクスの選択」をクリックしましょう。 そして、先ほど確認したメトリクスにチェックを入れて「メトリクスの選択」をクリック。 「メトリクスと条件の指定」では以下の条件で入力します。 期間のデフォルトは"5分"なので、今回は検証するためで短い間隔で実施します。 「条件」 ・しきい値の種類：静的 ・アラーム条件：より低い ・しきい値：1 ・アラームを実行するデータポイント：1/1 ・欠落データの処理：欠落データを不正(しきい値を超えている)として処理 「通知」 ・アラーム状態のトリガー：アラーム状態 ・SNSトピックの選択：お使いのアカウントに合わせて設定ください （今回は既存のSNSトピックを使っています。エンドポイントは自分のメールアドレスです。） 「EC2アクション」 ・アラーム状態トリガー：アラーム状態 ・アクション：このインスタンスの再起動 今回の要件はプロセスが停止した時にアラームが発生してEC2が再起動するかを確認することでしたので 上記のようにします。 「名前」 最終確認画面が出るので、問題がなければアラームを作成しましょう。 アラームが作成されて正常値確認ができていますね。 プロセスを停止してみる まずはサーバへログインし、httpdを停止しましょう。 [root@ip-10-0-1-10 ~]# systemctl stop httpd.service [root@ip-10-0-1-10 ~]# systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: inactive (dead) since Sun 2021-07-25 01:20:42 UTC; 5s ago Docs: man:httpd.service(8) Process: 2798 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=0/SUCCESS) Main PID: 2798 (code=exited, status=0/SUCCESS) Status: "Total requests: 1; Idle/Busy workers 100/0;Requests/sec: 0.000335; Bytes served/sec: 1 B/sec" Jul 25 00:30:49 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: Star... Jul 25 00:30:49 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: Star... Jul 25 01:20:41 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: Stop... Jul 25 01:20:42 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: Stop... Hint: Some lines were ellipsized, use -l to show in full. [root@ip-10-0-1-10 ~]# [root@ip-10-0-1-10 ~]# ps -ef | grep httpd root 3970 3923 0 01:21 pts/2 00:00:00 grep --color=auto httpd [root@ip-10-0-1-10 ~]# アラームを確認する アラームを確認するとアラームが発生していますね。 アラーム発生直後は、インスタンスへのSSH接続が切れていますので、再起動が成功していますね。 [root@ip-10-0-1-10 ~]# date Sun Jul 25 01:22:21 UTC 2021 [root@ip-10-0-1-10 ~]# Connection to 54.95.39.151 closed by remote host. Connection to 54.95.39.151 closed. メールも通知できています。 起動も確認できました。 メトリクスも正常値に復旧しました。

はじめに Lamdaの稼働環境ごとに異なる設定値を与えてデプロイしたくなりました。 AWS-SAMのテンプレートを使用して、環境ごとに設定を出し分けてみたので皆様にも共有いたします。 この記事ではAWS-SAMにフォーカスを当てております。 ただ、AWS-SAM自体がAWS CloudFormationのサービスをベースとしているので、そちらも併せてお調べいただくとより一層AWS-SAMに対して理解が深まると思います。 Lambda歴がまだ浅いので非効率なやり方をしているかもしれません。何かお気づきの点・気になる点ございましたらご指摘いただけると幸いです！ さらに良い方法をご存じの方がおられましたら、教えていただけますと嬉しいです?！！ どんな記事？ Lambda関数のデプロイ環境別（ステージングや本番など）に、異なる設定値を与えたい場面ってありませんか？この記事では、AWS-SAMのテンプレート（template.yaml）を用いた設定値の出し分けについて解説しています。なお、テンプレートの記述形式はYAMLを採用しています。 予備知識 AWS-SAM AWS-SAMとは、サーバーレス環境を自動構築してくれるAWS公式のツールです。Lambda関数等の設定をテンプレートファイル（YAML or JSON）に記述し、コマンドを実行するだけで、ローカル環境でのLambda関数のテスト実行やデプロイまで出来る優れモノです。 SAMテンプレート 以下でSAMテンプレートの各セクションについて概要的な説明がなされています。SAMテンプレートに初めて触れる方は、先に一読されることをお勧めします。 template.yaml Transform: AWS::Serverless-2016-10-31　 　SAMテンプレートをCloudFormationテンプレートに変換する。 Globals: 共通の設定。複数の関数があった場合、それぞれの関数はこの設定を継承する。 Description: テンプレートに関するコメント。 Metadata: メタデータ。 Parameters: テンプレート内で変数として利用する。また入力パラメータで任意な値を与えることができる。 　例えば、以下ではEnvという変数を定義している。この変数はSAM-CLIコマンド実行時に上書くことができる。 Env: Type: String Default: dev AllowedValues: [dev, stg, prd] Mappings: キーと名前付きの一連の値。 Conditions: TrueもしくはFalseだけを返す変数。 Resources: 使用したいAWSサービス。以下はLambda関数の場合。 TestFunction: Type: AWS::Serverless::Function Outputs: 他のスタックに情報を与える、応答として返す、AWS CloudFormationコンソールで表示する出力値を設定。 SAM-CLI設定ファイル SAMでは、AWS-SAM-CLIコマンドを用いてすべてを操作します。 AWS-SAM-CLIコマンドは、TOML形式の設定ファイルを読み込むことが出来ます。 デフォルトのファイル名はsamconfig.tomlです。 こんな感じのファイルです。 ここでは、parameter_overrides=["Env=環境名"]のようにパラメータに環境名を与えています。今回は、この入力パラメータを利用して環境ごとに設定値を出し分けていきます。また後で出てきます。 config.toml version = 0.1 [dev.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=dev", ] [dev.local_invoke.parameters] parameter_overrides = [ "Env=dev", ] [stg.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=stg", ] [prd.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=prd", ] 組み込み関数 SAMのテンプレートには組み込み関数が用意されています。もともとAWS CloudFormationが提供している機能を、SAM用に使いやすく拡張したものがSAMテンプレートです。実行時に動的に値が埋め込まれるので、実行するまで分からない情報は関数で表現しておきましょう。 組み込み関数の構文には、「完全名関数」と「短縮形」での2通り存在しています。これから列挙する関数はすべて短縮形で記載しています。また、記載していない関数もありますので、気になる方は公式のリファレンスをご参照ください。 関数 !FindInMap Mappingsセクションで宣言された2つのレベルのマッピングのキーに対応する値を返す。 !GetAtt テンプレートのリソースから属性の値を返す。 !Ref 指定したパラメータ（文字列）またはリソースの値を返す。 !Select オブジェクトリストからindexを指定して1つのオブジェクトを返す。 !Sub 文字列に変数を埋め込むことが出来る。 条件関数 !And !Equals !If !Not !Or 想定状況 Lambda関数のデプロイ先が3つある。 - 開発環境（dev） - ステージング環境（stg） - 本番環境（prd） 環境ごとに異なる環境変数やVPC、Roleなどの設定を付与したい。 デプロイコマンド デプロイ実行時にオプションで環境名を指定します。（＝入力パラメータ） SAMテンプレートでは、入力パラメータを利用して設定値を出し分けます。 sam deploy --config-env dev --config-envは、SAM-CLI設定ファイルが存在した場合に指定された環境の設定値をコマンドで使用します。 上記のコマンドでは、dev環境が指定されたので以下の情報が読み込まれます。 config.toml [dev.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=dev", ] また、SAM-CLI設定ファイルが存在していなくとも、以下のように環境名（＝入力パラメータ）を与えることもできます。 sam deploy --parameter-overrides Env=dev Mappingsと!FindInMapを使う方法 template.yaml Resources: TestFunction: Type: AWS::Serverless::Function Properties: Role: !FindInMap [Role, !Ref Env, Role] VpcConfig: SubnetIds: !FindInMap [VpcConfig, !Ref Env, SubnetIds] SecurityGroupIds: !FindInMap [VpcConfig, !Ref Env, SecurityGroupIds] Mappings: Role: dev: Role: arn:aws:iam::000000000000:role/test-function-role stg: Role: arn:aws:iam::111111111111:role/test-function-role prd: Role: arn:aws:iam::222222222222:role/test-function-role VpcConfig: dev: SecurityGroupIds: - sg-xxxxxxxx SubnetIds: - subnet-xxxxxxxxxxxxxxxxx stg: SecurityGroupIds: - sg-xxxxxxxxxxxxxxxxx SubnetIds: - subnet-xxxxxxxxxxxxxxxxx - subnet-xxxxxxxxxxxxxxxxx prd: SecurityGroupIds: - sg-xxxxxxxxxxxxxxxxx SubnetIds: - subnet-xxxxxxxxxxxxxxxxx - subnet-xxxxxxxxxxxxxxxxx Parameters: Env: Type: String Default: dev AllowedValues: [dev, stg, prd] Conditionsと!Ifを使う方法 template.yaml Resources: TestFunction: Type: AWS::Serverless::Function Properties: Role: !If [IsDev, 'arn:aws:iam::000000000000:role/test-function-role', !If [IsStg, 'arn:aws:iam::111111111111:role/test-function-role', !If [IsPrd, 'arn:aws:iam::222222222222:role/test-function-role', !Ref AWS::NoValue]]] Conditions: IsDev: !Equals [!Ref Env, dev] IsStg: !Equals [!Ref Env, stg] IsPrd: !Equals [!Ref Env, prd] Parameters: Env: Type: String Default: dev AllowedValues: [dev, stg, prd] Conditionsと!GetAttを使う方法 template.yaml AWSTemplateFormatVersion: "2010-09-09" Transform: AWS::Serverless-2016-10-31 Resources: RoleDev: Type: AWS::IAM::Role Condition: IsDev Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com RoleStg: Type: AWS::IAM::Role Condition: IsStg Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com RolePrd: Type: AWS::IAM::Role Condition: IsPrd Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com TestFunction: Type: AWS::Serverless::Function Properties: Role: !If [IsDev, !GetAtt RoleDev.Arn, !If [IsStg, !GetAtt RoleStg.Arn, !If [IsPrd, !GetAtt RolePrd.Arn, !Ref AWS::NoValue]]] Conditions: IsDev: !Equals [!Ref Env, dev] IsStg: !Equals [!Ref Env, stg] IsPrd: !Equals [!Ref Env, prd] Parameters: Env: Type: String Default: dev AllowedValues: [dev, stg, prd] 参考文献 この記事の情報は古くなっている可能性がありますので、実務でご使用の際はAWS公式リファレンスをご参照ください。

はじめに Lamdaの稼働環境ごとに異なる設定値を与えてデプロイしたくなりました。 AWS-SAMのテンプレートを使用して、環境ごとに設定を出し分けてみたので皆様にも共有いたします。 記述例だけを早く見せろ！という方はこちらから↓ SAMテンプレート記述例 この記事ではAWS-SAMにフォーカスを当てております。 ただ、AWS-SAM自体がAWS CloudFormationのサービスをベースとしているので、そちらも併せてお調べいただくとより一層AWS-SAMに対して理解が深まると思います。 Lambda歴がまだ浅いので非効率なやり方をしているかもしれません。何かお気づきの点・気になる点ございましたらご指摘いただけると幸いです！ さらに良い方法をご存じの方がおられましたら、教えていただけますと嬉しいです?！！ どんな記事？ Lambda関数のデプロイ環境別（ステージングや本番など）に、異なる設定値を与えたい場面ってありませんか？この記事では、AWS-SAMのテンプレート（template.yaml）を用いた設定値の出し分けについて解説しています。なお、テンプレートの記述形式はYAMLを採用しています。 予備知識 AWS-SAM AWS-SAMとは、サーバーレス環境を自動構築してくれるAWS公式のツールです。Lambda関数等の設定をテンプレートファイル（YAML or JSON）に記述し、コマンドを実行するだけで、ローカル環境でのLambda関数のテスト実行やデプロイまで出来る優れモノです。 SAMテンプレート 以下でSAMテンプレートの各セクションについて概要的な説明がなされています。SAMテンプレートに初めて触れる方は、先に一読されることをお勧めします。 template.yaml Transform: AWS::Serverless-2016-10-31　 　SAMテンプレートをCloudFormationテンプレートに変換する。 Globals: 共通の設定。複数の関数があった場合、それぞれの関数はこの設定を継承する。 Description: テンプレートに関するコメント。 Metadata: メタデータ。 Parameters: テンプレート内で変数として利用する。また入力パラメータで任意な値を与えることができる。 　例えば、以下ではEnvという変数を定義している。この変数はSAM-CLIコマンド実行時に上書くことができる。 Env: Type: String Default: dev AllowedValues: [dev, stg, prd] Mappings: キーと名前付きの一連の値。 Conditions: TrueもしくはFalseだけを返す変数。 Resources: 使用したいAWSサービス。以下はLambda関数の場合。 TestFunction: Type: AWS::Serverless::Function Outputs: 他のスタックに情報を与える、応答として返す、AWS CloudFormationコンソールで表示する出力値を設定。 SAM-CLI設定ファイル SAMでは、AWS-SAM-CLIコマンドを用いてすべてを操作します。 AWS-SAM-CLIコマンドは、TOML形式の設定ファイルを読み込むことが出来ます。 デフォルトのファイル名はsamconfig.tomlです。 こんな感じのファイルです。 ここでは、parameter_overrides=["Env=環境名"]のようにパラメータに環境名を与えています。今回は、この入力パラメータを利用して環境ごとに設定値を出し分けていきます。また後で出てきます。 config.toml version = 0.1 [dev.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=dev", ] [dev.local_invoke.parameters] parameter_overrides = [ "Env=dev", ] [stg.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=stg", ] [prd.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=prd", ] 組み込み関数 SAMのテンプレートには組み込み関数が用意されています。もともとAWS CloudFormationが提供している機能を、SAM用に使いやすく拡張したものがSAMテンプレートです。実行時に動的に値が埋め込まれるので、実行するまで分からない情報は関数で表現しておきましょう。 組み込み関数の構文には、「完全名関数」と「短縮形」での2通り存在しています。これから列挙する関数はすべて短縮形で記載しています。また、記載していない関数もありますので、気になる方は公式のリファレンスをご参照ください。 関数 !FindInMap Mappingsセクションで宣言された2つのレベルのマッピングのキーに対応する値を返す。 !GetAtt テンプレートのリソースから属性の値を返す。 !Ref 指定したパラメータ（文字列）またはリソースの値を返す。 !Select オブジェクトリストからindexを指定して1つのオブジェクトを返す。 !Sub 文字列に変数を埋め込むことが出来る。 条件関数 !And !Equals !If !Not !Or 想定状況 Lambda関数のデプロイ先が3つある。 - 開発環境（dev） - ステージング環境（stg） - 本番環境（prd） 環境ごとに異なる環境変数やVPC、Roleなどの設定を付与したい。 デプロイコマンド デプロイ実行時にオプションで環境名を指定します。（＝入力パラメータ） SAMテンプレートでは、入力パラメータを利用して設定値を出し分けます。 sam deploy --config-env dev --config-envは、SAM-CLI設定ファイルが存在した場合に指定された環境の設定値をコマンドで使用します。 上記のコマンドでは、dev環境が指定されたので以下の情報が読み込まれます。 config.toml [dev.deploy.parameters] stack_name = "test-stack" region = "ap-northeast-1" confirm_changeset = true capabilities = "CAPABILITY_IAM" parameter_overrides = [ "Env=dev", ] また、SAM-CLI設定ファイルが存在していなくとも、以下のように環境名（＝入力パラメータ）を与えることもできます。 sam deploy --parameter-overrides Env=dev SAMテンプレート記述例 Mappingsと!FindInMapを使う方法 template.yaml Resources: TestFunction: Type: AWS::Serverless::Function Properties: Role: !FindInMap [Role, !Ref Env, Role] VpcConfig: SubnetIds: !FindInMap [VpcConfig, !Ref Env, SubnetIds] SecurityGroupIds: !FindInMap [VpcConfig, !Ref Env, SecurityGroupIds] Mappings: Role: dev: Role: arn:aws:iam::000000000000:role/test-function-role stg: Role: arn:aws:iam::111111111111:role/test-function-role prd: Role: arn:aws:iam::222222222222:role/test-function-role VpcConfig: dev: SecurityGroupIds: - sg-xxxxxxxx SubnetIds: - subnet-xxxxxxxxxxxxxxxxx stg: SecurityGroupIds: - sg-xxxxxxxxxxxxxxxxx SubnetIds: - subnet-xxxxxxxxxxxxxxxxx - subnet-xxxxxxxxxxxxxxxxx prd: SecurityGroupIds: - sg-xxxxxxxxxxxxxxxxx SubnetIds: - subnet-xxxxxxxxxxxxxxxxx - subnet-xxxxxxxxxxxxxxxxx Parameters: Env: Type: String Default: dev AllowedValues: [dev, stg, prd] Conditionsと!Ifを使う方法 template.yaml Resources: TestFunction: Type: AWS::Serverless::Function Properties: Role: !If [IsDev, 'arn:aws:iam::000000000000:role/test-function-role', !If [IsStg, 'arn:aws:iam::111111111111:role/test-function-role', !If [IsPrd, 'arn:aws:iam::222222222222:role/test-function-role', !Ref AWS::NoValue]]] Conditions: IsDev: !Equals [!Ref Env, dev] IsStg: !Equals [!Ref Env, stg] IsPrd: !Equals [!Ref Env, prd] Parameters: Env: Type: String Default: dev AllowedValues: [dev, stg, prd] Conditionsと!GetAttを使う方法 template.yaml AWSTemplateFormatVersion: "2010-09-09" Transform: AWS::Serverless-2016-10-31 Resources: RoleDev: Type: AWS::IAM::Role Condition: IsDev Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com RoleStg: Type: AWS::IAM::Role Condition: IsStg Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com RolePrd: Type: AWS::IAM::Role Condition: IsPrd Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com TestFunction: Type: AWS::Serverless::Function Properties: Role: !If [IsDev, !GetAtt RoleDev.Arn, !If [IsStg, !GetAtt RoleStg.Arn, !If [IsPrd, !GetAtt RolePrd.Arn, !Ref AWS::NoValue]]] Conditions: IsDev: !Equals [!Ref Env, dev] IsStg: !Equals [!Ref Env, stg] IsPrd: !Equals [!Ref Env, prd] Parameters: Env: Type: String Default: dev AllowedValues: [dev, stg, prd] 参考文献 この記事の情報は古くなっている可能性がありますので、実務でご使用の際はAWS公式リファレンスをご参照ください。

リンク 【ポートフォリオ】 https://tasty-life.site/ 【Github】 https://github.com/YukiIshizaki0525/TastyLife はじめに 独学でサーバーサイド、フロントエンド、インフラを1から勉強し、Webアプリを作成しました。 本記事で、作成で苦労した点、各種機能、機能実装で参考になったサイトなどを記載いたしますので、現在ポートフォリオ作成中の未経験エンジニアやこれからポートフォリオを作ろうと考えている方のヒントとなれば幸いです。 機能実装方法やテストの書き方などより詳細な内容については別途Qiitaを投稿する予定ですので、更新をお待ちいただければと思います。 本記事についてのご質問や気になった点などがあればできる限り回答いたしますのでTwitterのDMやコメントでお知らせください。 【Twitterアカウント】 https://twitter.com/Luke19770525 概要 一人暮らしの自炊継続のモチベーションアップ及び脱マンネリ化したいという思いから制作 制作背景 私自身一人暮らしで、日々自炊を行っていて、以下のことが課題と感じています。 作る料理がマンネリ化してしまい、モチベーションが下がり、自炊を突然やめてしまう 一人暮らしの自炊についての相談できる機会がない 冷蔵庫に保管している食材を管理できていないため、腐らせてしまったり余っているのに買ってしまう そこで、上記課題を解決できる 一人暮らしの方の自炊を応援するアプリケーション を作成しようと決意しました。 今後の展望 自炊を行う知り合いに使ってもらっていて、ユーザーの貴重な意見を参考に日々改善を行っています。 今後、追加予定の機能及び変更点を5点ほど列挙します。 - アプリケーション自体をVue.jsでSPA化 - APIの導入 - 現在の食材管理状況を毎日18:00にメールで登録済みメールアドレスに配信 - 材料や作り方をドラッグ&ドロップして入れ替えられる仕様 - 作り方の画像プレビュー機能の追加 工夫した点 UI/UX - レシピを見て料理をする際はスマートフォンで見ることも多いのでレスポンシブデザインにしたこと - ページタイトル、文字色、ボーダー等の色を統一したこと - 一覧ページへ移動、削除、送信などをアイコンにして、直感的に操作できるようにしたこと - ホバーアクションやクリックアクションなどCSSアニメーションを取り入れ、動きのあるサイト構成にしたこと - 使いやすい導線設計 機能面 - 一人暮らしでの自炊での悩み（マンネリ化・食材管理など）を解決できるような機能を作成して、一般的なレシピサイトとの差別化を図ったこと - 作りたい料理が決まらない日が多いため、タグ検索機能を追加し、作りたい料理を決められる手助けとなるようにしたこと - 自炊を続けている方の相談や関心が高い相談を見て、自身の生活にも取り入れられるよう、相談のソート機能を追加したこと - 保存中の食材を把握しきれず無駄な買い足しや食材廃棄してしまっていたため、無駄な買い足しや食材廃棄を未然に防ぎ、余り物を有効活用できるよう、保存中の食材管理機能を追加したこと テスト - バリデーションやデザインに不備なく、ユーザーが安心してご利用いただけるようモデルスペック及びシステムスペックを十分に実施 ModelSpec結果 SystemSpec結果 学習で参考になったサイトや教材 ◎は非常に参考になった教材です。（個人の感想です） フロントエンド HTML/CSS/JavaScript ◎【JavaScript＆CSS】ガチで学びたい人のためのWEB開発徹底実践（フロントエンド編） 【JS】ガチで学びたい人のためのJavaScriptメカニズム サーバーサイド Ruby ◎プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Rails ◎Ruby on Rails チュートリアル ◎現場で使える Ruby on Rails 5速習実践ガイド ◎フルスタックエンジニアが教える 即戦力Railsエンジニア養成講座 パーフェクト Ruby on Rails テスト基盤 RSpec ◎Everyday Rails - RSpecによるRailsテスト入門 ◎【Rails】はじめてのRSpec！テストコードを書こう！ データベース ◎BigQuery で学ぶ非エンジニアのための SQL データ分析入門 ◎はじめてのSQL ・データ分析入門 -データベースのデータをビジネスパーソンが現場で活用するためのSQL初心者向コース インフラ Docker ◎Docker超入門講座 合併版 | ゼロから実践する4時間のフルコース ◎ゼロからはじめる Dockerによるアプリケーション実行環境構築 【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(1) AWS ◎AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得 ◎サルでもできる!? Rails6 のアプリをAWS EC2にデプロイするまでの全手順【前半】（VPC, RDS, EC2, Capistrano） 苦労した点 フロントエンド レスポンシブデザインのため、scssファイルを多く管理するのが大変でした。 JavaScriptでイベント発火時にエラーは出ないが挙動がおかしい場面が多く修復するのに苦労し、1日悩んでわからないことも多く断念したものもあります。今後はVue.jsをガッツリ勉強して対応できるようにしたい サーバーサイド 【レシピの材料及び作り方の非同期追加及び削除】の機能実装は苦労しました。Cocoon(Gem)を入れて当初実装していましたが、デザインが当たらなかったりなど、ブラックボックスに感じたので模索しながらGemを使わずに実装しました。こちらのサイトが唯一あって助かりました。 create a nested form in rails from scratch devise及びgmail認証 deviseもブラックボックスでカスタマイズするのに苦労しました。特にメール認証ではgmailにメールが届かないことが多く挫折しかけました。メール文章もデフォルトのものがあたってしまい、メール文章をカスタマイズするのにも一苦労しました。Qiitaの記事などを参考になんとか自身がイメージする形に仕上がったので良かったです。その関連でActionMailerについての知見も増え、gmailを使った退会処理機能などを実装することができました。 インフラ AWSとDockerの連携 ポートフォリオ作成初期にAWSとDockerを構築してから自動デプロイできるように努力しましたが、当初は敷居が高いと感じ、挫折しました。付け焼き刃では通用しないと思い、サイトや書籍を参考にチャレンジしたら、スムーズに構築することができました。何事も基礎がないとダメってことですね。 使用画面 トップページ ログインページ レシピ一覧(材料・レシピ名での検査、タグでのソートが可能です) レシピ詳細とコメント 相談一覧(回答数・気になる数などでソートが可能です) 相談詳細とコメント ユーザー詳細 食材管理ページ（自身のものしか見れません） 使用技術 フロントエンド HTML/CSS/Sass JavaScript(ES6) バックエンド Ruby 2.6.5 Rails 6.0.3 テスト基盤 RSpec 3.9 FactoryBot 4.10.0 データベース MySQL 5.7 インフラ Docker 20.10.7 Docker Compose 1.29.2 AWS(VPC, EC2, IAM, RDS, InternetGataway, SecurityGroup, Subnet, Route53, ALB, ACM, S3, CloudFront) Nginx 1.15.8 AWS構成図 ER図 機能一覧 基本機能 ユーザー新規登録(Gmail認証) ログイン・ゲストユーザーログイン ログアウト ログインセッション保持 ログインパスワード再設定(Gmail認証) アカウント認証メール再送 アカウントの凍結解除メール送信 ユーザー退会(論理削除) 退会済みユーザーアカウント復旧機能(Gmail認証) ユーザーアカウント情報変更(メールアドレス・プロフィール画像・ユーザー名・パスワード) メールアドレス変更(Gmail認証) フォロー中ユーザー一覧及びフォロワー一覧閲覧 ユーザーフォロー ユーザー詳細及びマイページ表示(レシピ・いいねしたレシピ・相談・気になっている相談・食材管理) ユーザー一覧 レシピに関する機能 ログイン済み レシピ投稿 材料及び作り方の非同期追加及び削除 レシピの画像添付(画像プレビュー可能) 作り方に画像添付 関連タグ付け(既定6つのタグ複数選択可能) レシピ一覧 レシピ詳細 レシピ編集(投稿したユーザーのみ) レシピ削除(投稿したユーザーのみ) コメント閲覧 コメント投稿 コメントに対する返信 コメント削除(投稿したユーザーのみ) レシピにいいねをつける レシピいいね数確認 ワードで検索(レシピ名及び材料名) 関連タグで検索 タイムライン(自身及びフォローしている方の投稿のみ表示) 未ログイン レシピ一覧 レシピ詳細 コメント閲覧 ワードで検索(レシピ名及び材料名) 関連タグで検索 相談に関する機能 ログイン済み 相談投稿 相談一覧 相談詳細 相談編集(投稿したユーザーのみ) 相談削除(投稿したユーザーのみ) 相談ソート(投稿が新しい順・投稿が古い順・気になるが多い順・回答数が多い順) コメント閲覧 コメント投稿 コメントに対する返信 コメント削除(投稿したユーザーのみ) 相談に気になる追加 相談気になる数確認 未ログイン 相談一覧 相談詳細 コメント閲覧 相談ソート 食材管理に関する機能 ログイン済みかつ自身のみ 保管中の食材追加・登録・編集・削除 食材画像,数量,個数,賞味期限,メモの登録 賞味期限までの日数確認 最後に ポートフォリオ作成は転職活動のために作成するのではなく、自身やユーザーの課題解決のために、ポートフォリオ制作を行うことに注力したので、非常に達成感があります。 ポートフォリオを使っていただいた方からありがたいことに改善点をいただいているので、作成途中よりも作成後の方がIssueが多いです(笑) ですが、実際にユーザーの生の声を聞いて、ユーザーのことをより考えながら改善や機能実装をしようと開発を進めているため、以前よりも幸せに感じながら実装ができています。 転職後も新しい技術に触れることが多いと思うので、インプットした後に本ポートフォリオに取り入れて、アウトプットの場にも使いたいと思います。 ここまでご覧いただきましたありがとうございました！

docker環境でrails6アプリを構築し、苦労してようやくEC2上にアプリをデプロイできたと思ったら、 何故かdeviseのユーザー登録時メール認証機能(comfirmable)、お問い合わせメール機能、ゲストログイン機能が500エラー。。。 メールに関する部分だけがエラーになっているからてっきりSMTPサーバーが機能していないのかな？などと推測し、 SESの設定を見直すも・・・・ 解決できず。。 原因:RDSで作成したMySQLのDBに日本語が保存できないこと RDSではDefaultでcharacter-setにlatin1が割り当てられるため、日本語を利用する際はutf8などに変更してあげる必要があったのでした。 そのためRDSで設定したMySQLに関するエラーが発生していました。 それに気づかずてっきりSMTPサーバー関係のエラーだと決めつけて数日もがいてました。。 そもそも私はログイン済みユーザーじゃないと新規投稿機能だったりフォローだったり、全ての機能を利用できないように制限をかけていたので 他のページの確認ができていなかったのですが、 本当はメールに関する部分だけがエラーになっていたのではなくて、 全体がエラーになっていたんだと思います。。。 解決につながったこと：エラーログの確認 エラーがどこで発生しているのか、原因の切り分けも大事ですが、エラーログを確認することが何より最も重要だと気づかされました。 docker環境でつくったアプリをEC2にデプロイしたら、本番環境のみエラーになってしまう。 開発環境ではエラーないのに。 その場合はどこでエラーログを見られるの？？ そもそもエラーログ出す方法なんてないんじゃないか？？ などと一週間くらいパニック状態でしたが（笑） ログの出し方が分かったことで2、3時間くらいで解決できてしまいました！！！ エラーログの出し方 [ec2]$ cd /var/www/アプリ名 [ec2]$ docker-compose exec app bash root@f4658ed2b15e:/var/www/アプリ名# cd /var/www/アプリ名 root@f4658ed2b15e:/var/www/アプリ名# ls root@f4658ed2b15e:/var/www/アプリ名# cd log root@f4658ed2b15e:/var/www/アプリ名/log# ls root@f4658ed2b15e:/var/www/アプリ名/log# tail -f production.log tail -fを使うことで、ページにアクセスしたときのエラーをリアルタイムで見ることができて便利です。 解決策：RDSの設定変更 下記記事の通りに設定したら解決しました。ありがとうございます！

前提 AWS CLIが入っていること create secret create secretをコマンドラインから行います。 createすると以下のように返されるはずです。 aws secretsmanager create-secret --region ap-northeast-1 --name DATABASE_URL --description "AWS Database URL" --secret-string xxxx.yyyyyy.ap-northeast-1.rds.amazonaws.com { "ARN": "arn:aws:secretsmanager:ap-northeast-1:xxxxxx:secret:DATABASE_URL-xxxxxx", "Name": "DATABASE_URL", "VersionId": "7c6cd5b1-e4ae-415f-zzzzzzz-xxxxxxxx" } AWS Secrets Managerに行くと、登録されているのが確認できます。 Secrets Manager読み取り権限の付与 読み取りのポリシーを追加します。 Attach inline policyから追加しました。たぶんここもスマートな方法があるのかと思いますが、とりあえずこれで、、、 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:ap-northeast-1:803801015105:secret:DATABASE_URL-xxxxxx" } ] } task definitionの整理 これをfargateのtask definitionのjsonファイルに貼り付けます。 task-definition.json # 必要なコンテナの定義に追加 "secrets": [ { "name": "DATABASE_URL", "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:803801015105:secret:DATABASE_URL-xxxxxx" } ] 参考