勉強前イメージ アーキテクチャを診断してくれる的な？ 調査 AWS Well-Architected Tool とは サーバーレスアプリケーションの評価ができる機能で、 AWSが定めた5つの柱でクラウド環境のシステム設計や運用を最適化するフレームワークです。 元々は今までのノウハウをホワイトペーパーで公開していたもので、 現在はAWS Well-Architected Toolとして統合され、誰でも改善を行うことができます。 5つの柱 AWSが定めた以下のような5つの柱で構成されており、 AWS Well-Architected Toolではそれぞれの設計思想の元、質問項目が準備されています。 運用上の優秀性 変更の自動化など日常業務を管理や、モニタリングなどの継続的な改善に焦点を当てています。 セキュリティ 情報とシステムの保護に焦点を当てて作っており、 権限管理やシステムの保護、セキュリティイベントの検知などを確立することが目的になります。 信頼性 意図した機能を期待通りに一貫して実行できることに焦点を当てており、 障害からの復旧や分散システムにの設定など考えることが目的になります。 パフォーマンス効率 リソースを効率的に使用することを目的としており、 要件に応じたリソースタイプやサイズ、ビジネスサイズの増大の対応など 情報に基づいて決定できます。 コスト最適化 ビジネスのサイズに応じたスケーリングをし、 不要なコストを回避することに重点を置いています。 使用するメリット レビューと評価ができる 全体をモニタリングしてリスクの把握に役立ちます。 またツールから次のステップを割り出します。 アーキテクチャガイダンスを利用できる 一連の質問に回答することでステップバイステップのアーキテクチャガイダンスを閲覧できます。 勉強後イメージ 今までのノウハウを使ってレビュー、また次どうしたらいいのか確認できるってことですかね 今ほぼ環境がないのでこちら使えませんが・・・悲しい 参考 AWS Well-Architected Toolをさわってみた AWS Well-Architectedの概念5つ｜行う時のポイントも紹介

記事のタイトルが長くなってしまったのですが、主要な構成は以下です。 アカウントA - APIGateway(IAM認証付き） - Lambda アカウントB - Lambda フロー アカウントB.Lambda　⇒　アカウントA.APIGateway　⇒　アカウントA.Lambda 細かく見ていきましょう。 Githubリポジトリ 今回記事で解説している構成を作成した際のソースをgithubにプッシュしました。 もし同じような構成を作っていて困っている方がいたら、ソースをいじってデプロイしてみてください！ ※使う際はいくつかのパラメータをご自身の環境に合わせて設定していただく必要があります。 注意 こちらの記事はPython, AWS SAMを利用しています。 Pythonではさらに、Boto3, aws_requests_auth のライブラリを利用しています。 動くところまでどうにか作ったものなので、もっと良い構成や実装、間違っている点があればご指摘頂けると勉強になります。 本記事の対象者 コアなケースですので、あまり対象者はいないかもしれません。それ故に情報が無かったので、記事にすることにしました。 AWSのAPIGateway, Lambda, IAMロールが分かる人 「APIGatewayにIAM認証をかける」が分かる人 SAM、又はCloudFormationを利用してAWSリソースをデプロイした経験がある人 他アカウントのLambdaからIAM認証をかけたAPIGatewayを呼び出したい人 構成について 今回実装した構成は、APIGatewayのアカウントとAPIGatewayを呼び出すLambdaのアカウントが別であり、APIGatewayにはIAM認証が必要という構成図です。 以下構成図です。 構成の詳細： APIGateway Account まず、こちらの構成の詳細を解説します。 APIGateway Accoutでは、IAM認証のかかったAPIGateway、呼び出し先のLambdaが基本の構成です。 こちらのAPIGatewayが別アカウントから呼び出され、最終的にLambda関数の結果が戻されます。 このアカウントでポイントとなるのが、IAMロールの存在です。 こちらのIAMロールのSAMテンプレートを見てみましょう。すべて見る必要は全くないです。ポイント１,ポイント２だけ見てください。 template.yaml APIGatewayRole: Type: "AWS::IAM::Role" Properties: RoleName: !Ref RoleName Path: "/" ManagedPolicyArns: - "arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs" Policies: - PolicyName: "authorizerLambdaInvokeAccess" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: #...............ポイント1：Lambda周りの権限も必要 - lambda:InvokeAsync - lambda:InvokeFunction - execute-api:Invoke Resource: "*" #...............ポイント2：このIAMロールを他で使えるようにAssumeRolePolicyを規定する AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Sid: "AllowApiGatewayServiceToAssumeRole" Effect: "Allow" Action: - "sts:AssumeRole" Principal: AWS: - !Sub "arn:aws:iam::${AnotherAccountID}:role/FromLambdaRole" ポイント1: Lambda周りの権限も必要 ポイント2: このIAMロールを他で使えるようにAssumeRolePolicyを設定する Lambda周りの権限も必要 今回の構成では、APIGatewayに渡ってきた認証情報を、APIGatewayのロールとして利用します。 詳しくは、以下の記事に書いた情報を確認ください。 そのため、APIGatewayがLambdaを実行できる権限も必要なため、その権限を付けています。 AssumeRolePolicyを設定する AssumeRolePolicyとは、STS（Security Token Serivce ）にてAssumeRoleする際に利用するPolicyです。 では、STSのAssumeRoleとはなんでしょう？ それは、IAMロールが持っている権限を一時的に別のユーザーやロールに付与する動作のことです。 今回はAPIGateway Accountで作成したIAMロールによってAPIGatewayのIAM認証を行うので、こちらのIAMロールの権限をLambda AccountのIAMロールに付与する必要があります。 そこで、AssumeRolePolicyに権限を付与する対象を記載しているのです。 以下を見てみましょう。 Principal: AWS: - !Sub "arn:aws:iam::${AnotherAccountID}:role/FromLambdaRole" 他アカウントのIAMロールであるFromLambdaRoleに「AssumeRoleをしてもよい」という許可を出しています。 構成の詳細： Lambda Account 次に、Lambdaアカウントの構成を解説します。 ポイントとなるのは、「APIGateway AccountのIAMロール」から権限をもらうことが許可されている、IAMロールです。 こちらのIAMロールをLambdaにアタッチすることで、Lambdaにて「APIGateway AccountのIAMロール」を利用することができます。そして、「APIGateway AccountのIAMロール」を使ってLambdaからAPIGatewayを呼び出すことができます。 呼び出し時のソースを見てみましょう。 app.py credentials = get_credentials() # ...............ポイント1: IAMの認証情報を取得する auth = AWSRequestsAuth( aws_access_key=credentials['AccessKeyId'], aws_secret_access_key=credentials['SecretAccessKey'], aws_host=aws_host, aws_region=REGION_NAME, aws_service='execute-api' ) headers = {'x-amz-security-token': credentials['SessionToken']} # ............... ポイント2: IAMの認証情報を送る response = requests.post( url, json={"foo": "bar"}, auth=auth, headers=headers) def get_credentials(): client = boto3.client('sts') IAM_ROLE_ARN = os.environ['IAM_ROLE_ARN'] IAM_ROLE_SESSION_NAME = 'other_account_session' response = client.assume_role( RoleArn=IAM_ROLE_ARN, RoleSessionName=IAM_ROLE_SESSION_NAME ) return response['Credentials'] ポイント1: IAMの認証情報を取得する ポイント2: IAMの認証情報を送る STSを利用し、IAMの認証情報を取得する 先ほどAPIGateway Accountの解説の際に出てきたSTSのAssumeRoleを利用し、IAMロールの認証情報を取得しています。 こちらをAPIGatewayを呼び出す際にヘッダーに渡してあげることで、IAM認証のかかったAPIGatewayを呼び出すことが出来ます。 IAMの認証情報を送る requests.postの中で、IAMロールの認証情報を一緒に送信して上げましょう。 response = requests.post( url, json={"foo": "bar"}, auth=auth, headers=headers) 以上のようにすることで、別アカウントからのAPI呼び出しが可能になります。 感想 1番辛かった作業は、SAMの書き方を調べながら書くことです。 SAMは使っている人が少ないせいもあり、なかなか情報が少ないです。 また、公式ドキュメントも最低限の情報しか書いてないので中々苦労します。日本語訳が割と雑なのはまだ良いのですが、英語で読んでも欲しい情報に中々辿り着けません。 今度IaCするときは、terraformとかを使ってみようかなと思いました。 参考記事

はじめに 株式会社オズビジョンにてエンジニア8年目のテラシマユウコ (@terra_yucco) です。 通常開発の他、オフショア開発のブリッジエンジニアや運用保守作業、企画のためのデータ出しなども担当させてもらっています。 （ここまでテンプレ） 前回記事「新米データサイエンスチームのこれまでとこれから」の他、いくつかのエントリでも触れていたように、今までオズビジョンでは分析基盤には BigQuery を利用していました。 BI 用途では Looker、Re:dash、Google Data Studio あたりが乱立していましたが、このたび「基盤も BI も AWS に統合しよう」という話になったため、これから直面する色々を含めて備忘録を書いていこうと思います。 なお、2021-10-14 現在、この話は現在進行形です。 なぜ統合することになったのか 下に色々書いたのですが、「分析者の要望を満たせているのは Looker だが、お値段が高すぎてデータが全員のものにできていない」「他の基盤は基本 AWS なのにここだけ GCP　にあるのが将来のリスク」というあたりが主な理由でした。 BI ツール乱立事件 Looker（パワフルだけどとにかく高い、なので使えるユーザ制限してた） Re:dash（自分でSQL書ける人向け）、 Google Data Studio（まあ元データがBigQueryだからね…） アプリの基盤、分析したいデータのオリジナルはほぼ全て AWS にある GA や Firebase 関係は除く 「とにかくデータの見える化を！」で社内の色々な人が連携取らずに動いてしまったので、各々が正しいと思い込んでいるデータがあちこちにある状態になり、ガバナンスの効いていないデータから謎数値が提示されることが増えた どんな風に構成を変えるのか 既存 AWS Aurora の定期 snapshot から Parquet 生成 Parquet を BigQuery 転送し、全件洗い替えでデータ反映 BigQuery 側の Scheduled Query 機能で必要な ETL や集計を実施 Looker をはじめとしたツールで可視化・分析 これから（希望） AWS Aurora の定期 snapshot から Parquet 生成【変更なし】 AWS Glue Data catalog で database を定義し、上記 Parquet でテーブルを作成 Athena を利用して ETL や集計を実施 QuickSight を利用して可視化・分析 まとめ データの民主化とコストの問題から、今まで GCP に寄っていた分析基盤を AWS に寄せることになりました。 次以降の記事では、移行検討でぶちあたっている壁について書こうと思います。

2021年9月に Amazon MemoryDB for Redis が一部のリージョンからリリースされました。 Usage Fee 公式ドキュメントからAWS Elastic Cache for Redisと比較してみました。 MemoryDB においても東京リージョンでの利用料金が公開されているようです。 Amazon ElastiCache の料金 https://aws.amazon.com/jp/elasticache/pricing/ Amazon MemoryDB for Redis Pricing https://aws.amazon.com/jp/memorydb/pricing/ ノード スペックが同じ単一ノードの料金を比較した場合、MemoryDB が1時間あたり $0.124 ほど高いようです。また、ElastiCache はリザーブドノードが適用対象に対して、MemoryDB はオンデマンドのみ適用可能となるようです。 サービス キャッシュノードタイプ vCPU メモリ (GiB) ネットワークパフォーマンス 1時間あたりの料金 MemoryDB db.r6g.large 2 13.07 Up to 10Gib $0.371 ElastCache cache.r6g.large 2 13.07 Up to 10Gib $0.247 スナップショット MemoryDBのスナップショットはクラスター全体のコピーを示すものです。 リージョン内のMemoryDBクラスターで総ストレージ量の100%まではスナップショットの追加料金は発生しません。保存期間が1日の場合、スナップショットの追加料金はありません。 追加のスナップショットストレージがストレージ料金$0.023/GB-monthで請求されるようです。 これに対して、ElastiCacheでは自動スナップショット、および手動スナップショットがクラスターごとに、1 つのスナップショットのストレージ領域を無料で利用できますが、追加のバックアップストレージは、$0.085/GB-monthほどかかってくるようです。 状況次第ですが、ElastiCacheの方が高いように感じます。 ElastiCache for Redis MemoryDBに入る前にElastiCache for Redisの構成について考えます。 ElastiCache for Redisは、ノードをキャッシュサーバーとして立てて、多様な構成を取ります。 シャード 複数ノードをもつ集合体を一つのグループとして定義します。 このグループには、読み書き可能な Primaryノードと 読み取り専用の Replica ノード(0~5ノードまで)が属します。 また、Primaryノードのみを使用する単一のシャードも可能です。 各シャードで slotがあり、スロット範囲を均等分散あるいはカスタム値で分散する事が可能です。これにより、スロットの範囲に応じてデータが分散され格納されます。 クラスター シャードをまとめたグループです。 クラスターモードと呼ばれ、無効化する事も可能です。クラスタモードが無効な場合、Redis は１つのシャードで構成されます。 クラスターが有効な場合、シャードを最大で500個まで増やす事が可能で、シャードの数が多いほどデータの分散化が可能です。クラスタは2つのサブネット(AZ)が必要となり、クラスターモードが無効でもシャードを介したレプリケーション自体はサポートされます。 Redis レプリケーショングループ レプリケーショングループとは、前述に挙げた以下の構成でレプリケーションが行われるグループ単位です。 クラスタが無効化の状態ですべてのデータが単一シャードに含まれているケースでは、1 つの Primary ノードと、最大5個のReplicaノードで構成され、Replicaノードは、クラスターのプライマリノードにあるデータのコピーを非同期レプリケーション機能により保持します。 クラスタが有効化の状態で、最大 500 個のシャードに渡ってデータが分割されるケースでは、1 〜 500 個のシャードで構成され、1 つの Primary ノードと、最大5個のReplicaノードで構成されます。シャード内の各リードレプリカは、シャードのプライマリからのデータのコピーを非同期レプリケーション機能により実装しています。 障害時のプロセス Primary ノードに障害が発生した場合のプロセスです。 クラスタが無効な場合 ① ElastiCache がPrimary Nodeで失敗を検出します。 ② ElastiCache がPrimary NodeをOFFLINEにします。 ③ ElastiCache が新しいPrimary Nodeを作成してプロビジョニングし、失敗したPrimary Nodeと置き換えます。 ④ ElastiCache が、新しいPrimary Nodeを既存のReplica Nodeのいずれかと同期させます。 ⑤ 同期が終了すると、新しいノードはクラスターのPrimary Node となります。 このプロセスのステップが終了するまで、アプリケーションはプライマリノードに書き込めません。ただし、アプリケーションはレプリカノードから読み込みを続けることができます。 クラスタ有効化の場合 ① ElastiCache がPrimary Nodeで失敗を検出します。 ② レプリケーションの遅延が最も小さいReplica NodeをPrimary Nodeに昇格します。 ③ 他のレプリカと新しいPrimary Nodeを同期します。 ④ 障害が発生したプライマリの AZ のReplica Nodeをスピンアップします。 ⑤ 新しいノードが、新たに昇格されたPrimary Nodeと同期されます。 レプリカノードへのフェイルオーバーは、通常、新しいプライマリノードを作成してプロビジョニングするより高速です。 つまり、マルチ AZ が有効でない場合と比べて、アプリケーションはプライマリノードへの書き込みをすばやく再開できます。 Amazon MemoryDB for Redis ElastiCache for Redis に比較します。 MemoryDBでは、Redis クラスタが必須の構成となります。 その他、構成に大きく違いはありません。 ノードの配置で考えると、クラスタ毎のシャード数、レプリカ数を選択する事となります。 障害時のプロセス MemoryDB のノードに障害が発生した場合のプロセスです。 ElastiCache と挙動が少し異なるようです。 リードレプリカ ①MemoryDBがreplica Nodeの障害を検出します。 ②MemoryDBは対象Replica NodeのをOFFLINEにします。 ③MemoryDBは、同じAZで代替ノードを起動してプロビジョニングします。 ④新しいノードは、トランザクションログと同期します。 この間、アプリケーションは他のノードを使用して読み取りと書き込みを継続できます。 プライマリー ①MemoryDB がPrimay Nodeの障害を検出します。 ②MemoryDB は、障害が発生したプライマリとの整合性を確認した後、レプリカにフェイルオーバーします。 ③MemoryDBが故障したプライマリのAZにレプリカをスピンアップする。 ④新しいノードは、トランザクションログと同期します。 レプリカノードへのフェイルオーバーは、通常、新しいプライマリノードを作成してプロビジョニングするよりも高速です。つまり、アプリケーションはより早くプライマリノードへの書き込みを再開することができます。 Let's use it 東京リージョンは正式にリリースされていないようでしたので、バージニアリージョンで作成しました。 クラスターが必然的な設定となるので、シャードとレプリケーション数だけを指定します。 クラスターの作成が完了した後、ガイダンスに従って、AmazonLinux2から接続を redis へ接続します。 $ sudo yum -y install openssl-devel gcc $ wget http://download.redis.io/redis-stable.tar.gz $ tar xvzf redis-stable.tar.gz $ cd redis-stable $ make distclean $ make redis-cli BUILD_TLS=yes $ sudo install -m 755 src/redis-cli /usr/local/bin/ Redis に接続する際は以下のコマンド redis-cli -h <Cluster Endpoint> --tls -p 6379　-c データは追加できました。 set test2 2 -> Redirected to slot [8899] located at memorydb-redis-cluster-0002-001.memorydb-redis-cluster.xxxx.us-east1.amazonaws.com:6379 OK 設定ファイル(config)の確認できないようです。 > config * (error) ERR unknown command `config` bgsaveやAOFは使えないようです。 > bgsave (error) ERR unknown command `bgsave` > bgrewriteaof (error) ERR unknown command `bgrewriteaof`, with args beginning with: 特定時点のスナップショットは自動/手動で取得できるようです。 手動のフェイルオーバーは可能なようです。 書き込み中のPrimary ノードに障害を意図的に発生させて、フェールオーバー後のトランザクションに差異が無いかを確認出来ればよいのですが、方法が見当たらず一旦断念。 Usability - ドキュメントからは、いずれのノードも一貫性を保つため、障害時にデータロストをする事は無いと記載がありますが、肝心のトランザクションログがMemoryDB の画面からも確認出来ず、 S3 や Cloudwatch にも無いようだったので、具体的にどこに保管されているかが可視化出来ませんでした。 - 任意に取得した時点のスナップショットから復元は可能なようですが、PITR(ポイントインタイムリカバリー)はどうやら使えないようです。 Consideration MemoryDB for Redis を採択するメリットを考察してみます。 MmoryDBは処理をMulti-AZ トランザクションログ で管理し、データの書き込み操作が成功すると、クライアントに戻る前に分散したMulti-AZトランザクションログに永続的に保存されます。 Primaryノードに対する読み込み操作は、それ以前に成功したすべての書き込み操作の影響を反映して、常に最新のデータを返すプロセスとなっているようです。 この観点からトランザクションログが先行してデータの整合性を保持しているため、ノードダウンによる、データロストが無い、あるいは一貫性が保たれるという事が考えられます。 一方、ElastiCache for Redisは、多様な構成を取りつつも、データロストを最小限に抑える事が重要であり、障害の軽減という観点からドキュメントの記載があります。 レプリケーショングループについては、障害の影響を最小限に抑えるために、各シャードに複数のノードを実装して、複数のアベイラビリティーゾーンにノードを分散することが推奨されていますが、ElastiCache for Redis のレプリケーションは非同期で行われます。そのため、プライマリノードが他方のAZのレプリカへフェイルオーバーする際に、レプリケーションの遅延のためにデータが失われる可能性があるようです。 Elastic for Redisでは、Redis のデータ永続化するための機能にあたる AOF(Append Only File) が、Redis バージョン 2.8.22 以降サポートされていないようです。 また、マルチ AZ レプリケーショングループ(複数のAZに跨るレプリケーショングループを構成しているクラスタ)では、AOF は有効化出来ません。 そして、物理サーバー上のハードウェア障害が発生し、ノードにエラーが発生した場合、ElastiCache は別のサーバーで新しいノードをプロビジョニングします。この場合、AOF ファイルは使用できなくなり、データの復旧には使用できません。 その他の対策としてバックアップ(BGSAVE)がサポートされています。 Redis .rdb のバックアップを書き込み時には、キャッシュメモリを使用し、書き込み負荷に高いメモリを使用する場合に、キャッシュへの書き込みが遅延します。 この遅延により、ほとんどの変更が累積されないため、結果バックアップが正常に行われなくなります場合もあり、上述した追加のバックアップのストレージ領域については $0.085/GB の料金が発生します。 ElastiCaheではトランザクションによる一貫性が担保されていないため、データロストの可能性がある事が考えられ、これを最小限に抑えるためにはコスト、パフォーマンスに影響を与える構成にする必要があると考察しました。 MemoryDB for Redis は、ElastiCache for Redis に比べて書き込みが多少遅く、運用コストも高いようですが、データロスト、障害時のリスクという観点からこちらを採択する条件もあるのではないかと考えます。 しかしながら、検証不足かつまだリリース間もなく情報も少ないため、これから採択に向けて情報収集していきたいと思います。 Appendix MemoryDBは ElastiCache for Redisから取得したスナップショット(.rdb) を元に MemoryDBとしてリストアが可能なようです。 いずれも比較をしていましたが、移行自体も出来るようです。 参考文献 Amazon MemoryDB for Redis Developer Guide

まえがき タイトルどおり、AmazonのLightsail上で、Multisite構成でないwordpress環境を複数作って サブドメインで分けるところまでやっていきます。 参考記事を見ながら作業をしていましたが、 現在、Lightsailで新しく作成したbitnamiのwordpressでは、ディレクトリ構造が変わっているようなので記事にしてみました。 本家の英語ドキュメントではふたつのやり方があることが記載されておりコマンドで自分の環境を調べることができることが記載されています。 注：現在、多くのBitnamiスタックのファイル構造と構成を変更しています。これらの変更により、このガイドに記載されているファイルパスは、お使いのBitnamiスタックがネイティブのLinuxシステムパッケージを使用しているかどうか（アプローチA）、または自己完結型のインストールであるかどうか（アプローチB）に応じて変更される可能性があります。お使いのBitnamiのインストールタイプと従うべきアプローチを特定するには、以下のコマンドを実行してください。 $ test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation." Approach A: Using system packages. と帰ってきました。 私の環境ではアプローチAということがわかりました。 日本語記事で多いのはファイル構成変更前のアプローチBです。 やりたいこと apacheのヴァーチャルホスト機能を使って複数のワードプレスをひとつのインスタンス上で機能させたい。 具体的には ・wp.mydomain.com というワードプレスを最初に作ったので、 ・wp1.mydomain.com ・wp2.mydomain.com ・wp3.mydomain.com というアドレスでアクセスできるwordpressサイトを複数作ろうというものです。 参考にした記事のように、複数人のwordpress学習環境としての用意です。 「.htaccess」を有効にする Bitnamiのhttpd.confは、「/opt/bitnami/apache2/conf」配下にあります。 210行目あたりにAllowOverrideの項目があるので、設定内容をNoneからAllへ変更します。 /opt/bitnami/apache2/conf/httpd.conf <Directory /> AllowOverride All Require all denied </Directory> Apacheを再起動します。 $ sudo /opt/bitnami/ctlscript.sh restart apache phpmyadminを操作できるようにする。 Bitnamiでは、「phpMyAdmin」が実質上利用不可となっているので、利用可能とします。 これはセキュリティ上当然の判断で、デフォルトでWordPressを使うだけの人には「phpMyAdmin」が不要ですし、全世界からアクセス可能とすることはリスクがあります。リスクを理解して作業を行ってください。 とのことで、少しリスクの伴うやり方なようです。 操作後、戻す設定にすると思います。 phpmyadminの設定ファイルへ追記、変更をしていきます。 先頭4行目あたりまでだけで設定できます。 /opt/bitnami/apache2/conf/bitnami/phpmyadmin.conf Allow from All Require all granted Apacheを再起動します。 $ sudo /opt/bitnami/ctlscript.sh restart apache IPアドレス末尾に「/phpmyadmin/」を追加してアクセスします。 ログインユーザーはroot、パスワードはbitnami初期パスワードです。 ですので、homeディレクトリにbitnami_credentialsがあるはずなので、vi等で開くと確認できます。 $ vi ~/bitnami_credentials 別のWordpressを環境を用意する デフォルトのwordpressの場所は、/opt/bitnami/wordpressになります。 ここと同じ階層に/opt/bitnami/wordpress1とかを作っていきます。 まずは、wordpressを取得します。 ホームディレクトリあたりで取得。 $ wget https://ja.wordpress.org/wordpress-5.8.1-ja.zip 解凍(unzip)します。 $ unzip wordpress-5.8.1-ja.zip wordpressというディレクトリが出来上がっていると思うので、公開したいフォルダへコピーします。 $ cp -R ./wordpress /opt/bitnami/wordpress1 所有ユーザ、権限まわりを変更していきます。 $ cd /opt/bitnami $ sudo chown -R bitnami:daemon wordpress1 $ sudo chmod -R g+w wordpress1 ヴァーチャルホストの設定 bitnamiのapacheの設定は/opt/bitnami/apache2/conf/httpd.confです。 そのファイルの末尾(520行目あたり)でOptinalとしてvhostフォルダ内がまとめてインクルードされている設定が確認できます。 /opt/bitnami/apache2/conf/httpd.conf IncludeOptional "/opt/bitnami/apache/conf/vhosts/*.conf" 初期のwordpressのヴァーチャルホスト設定もここにあることも確認しましょう。 $ bitnami@ip-YOUR-OWN-IP-ADR:/opt/bitnami/apache2/conf/vhosts$ ls -1 00_status-vhost.conf htaccess wordpress-https-vhost.conf wordpress-vhost.conf ここに新しいヴァーチャルホストの設定ファイルを作成します。 $ cd /opt/bitnami/apache2/conf/vhosts $ touch wordpress1-vhost.conf このあたりからは細かい調整がまだ済んでいませんが、最小構成で動作確認用にこんな設定にしてみました。 <VirtualHost 127.0.0.1:80 _default_:80> ServerName wp1.mydomain.com ServerAlias www.mydomain.com DocumentRoot /opt/bitnami/wordpress1 <Directory "/opt/bitnami/wordpress1"> Options -Indexes +FollowSymLinks -MultiViews AllowOverride All Require all granted </Directory> </VirtualHost> DNSの解決のサブドメインを設定 最後にRoute53のドメインサービスの方で、割り当てたサブドメインのAレコードを記載して、名前解決できるようにします。 route53だとほんの1分ほどで名前浸透するので安心です。 phpmyadminで新しいデータベースを作成 上の方で設定したphpadminから新しいデータベースを作成します。 siteにアクセス ブラウザからサイトにアクセスしてwordpressの初期設定を行います。 同じサーバーでヴァーチャルホストの設定ができました。 あとは通常のワードプレスのように使っていくことができます。 細かいリライトの設定などはまた調べて追記していきたいと思います。 参考記事に記載のアプローチAを参考にファイル構造などを把握していくことが必要です。 参考

はじめに Azure IoT HubとAws IoT Core似たようなサービスだけど、何が違うの？と疑問に思っている方も多いと思いますので、比較してまとめてみようと思います。 今回の比較対象 Azure IoT hubとAws IoT Core Azure IoTHubとAws IoT Coreについて Azure IoTHub 各デバイスとクラウドを繋ぎ、双方向に通信が可能 各デバイスをクラウド上で管理/監視が可能 何十億のデバイスの通信が可能でセキュリティーは、高いチャンネルで守られているため安心 最大で7日間イベントデータを保持することができる Aws IoT Core 各デバイスとクラウドを接続することができる デバイスがオフラインの状態でも最後に通信した情報を保持することができる 接続されたデバイスは、高度な暗号化がされ、身元がわからない外部のデバイスからの干渉を防ぐことができる デバイスから送られてくるデータが閲覧しやすい（閲覧のやり方が簡単） 違う所 Azure 各デバイスにIoTHubで管理/監視ができる 7日間イベントデータを保持 AWS デバイスがオフラインの状態でも最後に通信した情報を保持 接続されたデバイスは、高度な暗号化される デバイスから送られてくるデータが閲覧しやすい 各サービス作成手順 NO Azure IoT Hub Aws IoT Core 1 リソースを作成する 　 2 IoTHubを作成する 3 デバイスを作成する モノを作成する 4 証明書を作成する 5 ポリシーを作成する 6 証明書にポリシーをアタッチする 7 証明書にモノをアタッチする 8 送信側のプログラムを作成する 送信側のプログラムを作成する 手順でみたらAzureの方が楽ですね。 料金について Azure IoTHubは従量課金ではなくプランが用意されています Azure IoTHub料金プラン ※ 価格レベルBシリーズ(Basic)のサービスプランは、トラフィック処理が低く、トラフィック管理機能が不要なアプリ向け ※ 価格レベルSシリーズ(Standard)のサービスプランは、実稼働で実行されることを想定 BasicとStandardの利用可能な範囲 Azure IoT Hub 課金レベル 1日あたりのメッセージ数 メッセージの課金サイズ 一か月あたりの料金 無料 　8000 0.5kb 無料 S1 400,000 4kb ￥2,800 S2 6,000,000 4kb ￥28,000 S3 300,000,000 4kb ￥280,000 B1 400,000 4kb ￥1,120 B2 6,000,000 4kb ￥5,600 B3 300,000,000 4kb ￥56,000 シミュレーション 無料プランの場合 接続デバイス数 1台、12秒に1メッセージでデータサイズ0.5kb以下を送り続ける 3600秒(１時間) ÷ 12 × 24 = 7200 一日：7200メッセージ ちなみに、11秒に一回送信する場合1日7854.....なのでぎりいける Aws IoT Core Aws IoT Coreは、従量課金になります Aws IoT Core料金 料金計算ツール AWS IoT Core料金計算ツール IoT Coreも12か月の無料枠があるそうです。 無料枠詳細 機能 詳細 接続時間 　2,250,000分（12時間） メッセージ 500,000 件 レジストリまたはデバイスシャドウのオペレーション 225,000 回 トリガールール 250,000 件 IoT Coreでは、データサイズ5kbまでらしいです。（例えば6kb超える場合は、メッセージ数2件として計算されるみ たい） 上記の料金ツールで色々計算してます。 接続デバイス数 1台、12秒に1メッセージでデータサイズ0.5kb以下を送り続ける 接続時間：24時間 1日：7,200メッセージ 30日：216,000メッセージ 料金：毎月0.26 USD（29.52円）？ 接続デバイス数 1台、5秒に1メッセージでデータサイズ4kb以下を送り続ける 接続時間：24時間 1日：17,280メッセージ 30日：518,400メッセージ 料金：毎月0.62 USD（70.41円）？ まとめ IoT Coreの料金が安すぎる気がしますね。？（間違っているかも） 本当にこんなに安かったらAws IoT Coreを使った方がいい気がしますが。、どうなんでしょう？ 各サービスの作成手順は、Azure IoT Hubのほうが手順が少ないし、メモするkeyも一つでいいので楽ですね。

AWS初心者がAWSを触ってみたいと思い、EC2上にWebサーバーを構築することにしました。 長くなりそうなので何回かに分けて作業、投稿しようと思います。 不備があればご指摘頂けると助かります。よろしくお願いします。 本記事の環境 AWSのIAMユーザー ホストOS：Windows10 Pro 64bit 16GB ゲストOS：Amazon Linux 2 Tera Term：4.105 Apache：本記事では未導入。追々実施予定。 php：本記事では未導入。追々実施予定。 データベース：本記事では未導入。追々実施予定。 ※別途、運用資金も必要です。 構築手順 手順１：仮想マシンの起動 画面右上のリージョンを東京にする。※任意です。 「仮想マシンの起動」を選択する。 手順２：Amazonマシンイメージ(AMI)の選択 「Amazon Linux 2 AMI」を選択する。※任意です。 手順３：インスタンスタイプの選択 「t2.mirco」を選択する。※任意です。 「次のステップ：インスタンスの詳細の設定」を選択する。 手順４：インスタンスの詳細の設定 実施したいことに合わせて設定を変更する。※今回はそのままにしました。 「次のステップ：ストレージの追加」を選択する。 手順５：ストレージの追加 実施したいことに合わせて設定を変更する。※今回はそのままにしました。 「次のステップ：タグの追加」を選択する。 手順６：タグの追加 「クリックして Name タグを追加します」を選択する。 値に任意の文字列を入力する。 「次のステップ：セキュリティグループ」を選択する。 手順７：セキュリティグループの設定 「セキュリティグループ名」と「説明」に任意の文字列を入力する。 SSH、HTTP、HTTPSを設定する。 「確認と作成」を選択する。 手順８：インスタンス作成の確認 「起動」を選択する。 手順９：新しいキーペアの作成 プルダウンにて「新しいキーペアの作成」を選択する。 「キーペア名」に任意の文字列を入力する。 「キーペアのダウンロード」を行う。ダウンロードしたもの(拡張子がpemのファイル)は任意の場所に保管する。 「インスタンスの作成」を選択する。 手順１０：インスタンスの表示 「インスタンスの表示」を選択する。 手順１１：状態チェック。 画面を見ながら、初期化が落ち着くまで少し待つ。 「パブリック IPv4 DNS」と「パブリック IPv4 アドレス」をメモする。 手順１２：Tera TermでSSH接続する。 「パブリック IPv4 アドレス」を入力する。 先程ダウンロードした「キーペア(拡張子がpemのファイル)」を選択する。 SSHで接続する。 (補足)手順１３：(一定期間使わない場合は、)インスタンスを停止する。 「インスタンスの状態」からインスタンスを停止する。再度使用するときは、「インスタンスの状態」からインスタンスを開始する。※停止しないと「利用している」と判断されるため。 今後の見通し Apacheをインストールする。 phpをインストールする。 データベースの作成。 参考 https://qiita.com/harufuji/items/4fcd8f991fab5ad3354a#ssh%E3%81%A7%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%AB%E6%8E%A5%E7%B6%9A%E3%81%99%E3%82%8B https://qiita.com/kono-hiroki/items/86af406d95f325b32e4e https://qiita.com/gyu_outputs/items/f0ab345402362e43db80 https://qiita.com/tseno/items/47ae835933fd919772e6

リージョン全域にわたる停止からの災害復旧機能と低レイテンシ―でのグローバルな読み取り機能を備え、最大6つのAWSリージョンにまたがることのできる単一のデータベース。 プライマリリージョンの変更や災害復旧訓練などのシナリオにおける計画されたフェイルオーバープロセスが簡素化。

OpenShift LoggingのElasticSearchは、正直ちょっと安定的に運用するのが普通は無理だと思うので、それでもログ集約してGUIでログ参照したい場合はAmazon CloudWatch Logsに転送するのが現状はベストじゃないかと思う。オンプレ環境だったとしても。 ClusterLogForwarderでのCloudWatchへのログ転送が、たぶんROSAのGAに関連してだと思うが、OpenShift 4.8から出来るようになっている。 以下はそのやり方。簡単。 １．AWSでIAMユーザーとアクセスキーを作成する AWSのIAMで、認証タイプがアクセスキーのユーザーを作る。 アクセス許可にCloudWatchFullAccessを付ける。 タグは任意で。ユーザーを作成したらアクセスキーIDとシークレットアクセスキーを手に入れる。 例えば アクセスキーID: AKIASBHLFJQFVNNFOGOT シークレットアクセスキー: 4rGScURvVfAgdZppB9+KNzB+y0ZdqMuOJD5U2FxL OpenShiftでBase64にした文字列が必要なので、base64コマンドか適当なWebのアプリでbase64変換しておく。 アクセスキーID(base64): QUtJQVNCSExGSlFGVk5ORk9HT1QK シークレットアクセスキー(base64): NHJHU2NVUnZWZkFnZFpwcEI5K0tOekIreTBaZHFNdU9KRDVVMkZ4TAo= ２．OpenShiftでLoggingオペレーターを導入する OperatorHubからLoggingオペレーターを導入する。 なおClusterLogForwarderを使いたいだけだったら、ElasticSearchを前提オペレーターとして導入する必要はない。 オペレーターがインストールされたら、ClusterLoggingのインスタンスを下記のyamlで作成する。 ElasticSearch、kibanaを導入しないので、logStore、visualizationのスタンザが不要。 apiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: "openshift-logging" spec: managementState: "Managed" collection: logs: type: "fluentd" fluentd: {} ３．ClusterLogForwarderを設定する まずは、AWSにアクセスするためのsecretを作る。 画面右上の「＋」をクリックして以下を入力、アクセスキーIDとシークレットアクセスキーを先ほど入手したbase64エンコード済みのものに置き換え、作成。 apiVersion: v1 kind: Secret metadata: name: cw-secret namespace: openshift-logging data: aws_access_key_id: QUtJQVNCSExGSlFGVk5ORk9HT1QK aws_secret_access_key: NHJHU2NVUnZWZkFnZFpwcEI5K0tOekIreTBaZHFNdU9KRDVVMkZ4TAo= 同じく「＋」ボタンから作ってもいいのだが、一応OperatorのClusterLogForwardersからClusterLogForwarderの作成から、下記のyamlで作成する。 groupPrefixはオプションだが、指定すればCloudWatch Logsに「my-cluster.audit」みたいな形でロググループが作成される。 region: ap-northeast-1 は、東京に作るの意。 apiVersion: "logging.openshift.io/v1" kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging spec: outputs: - name: cw type: cloudwatch cloudwatch: groupBy: logType groupPrefix: my-cluster region: ap-northeast-1 secret: name: cw-secret pipelines: - name: infra-logs inputRefs: - infrastructure - audit - application outputRefs: - cw ４．ログが転送されていることを確認する 設定後、割とすぐにCloudWatch Logsに以下の画面のようなロググループが作成される。 作成されない場合は、IAMユーザーのアクセス権が違うか、Secretが間違っているか。 openshift-logging/fluentd-*のログを参照すると原因がわかる事があるかも。 AWS側、Log Insightsを使って転送されたログを解析することができる。 指定するクエリは、infrastructureの場合はfieldsの「@message」から@を外して「message」としたほうが見やすい。

試験を受けたのは何者なのか？ エンジニア未経験の文系大学出身の公務員　33歳 独学で学んだVBAによる業務改善がきっかけで、プログラミングと出会い、エンジニア転職を目指す 新卒後、VBAと出会う(32歳)まで仕事やプライベートでプログラミングに触れたことがない素人 体育会系のノリが好きで、パソコンとは縁もゆかりもない１児の父親 AWS歴　 実務案件に挑戦した42日間　実務案件詳細記事はこちら SAA試験について簡単に AWS公式の受験対象者について AWS 認定ソリューションアーキテクト – アソシエイトは、AWS における、可用性があり、コスト効率が高く、高耐障害性で、スケーラブルな分散システムの設計に関する 1 年以上の実務経験を持つ方を対象としています。 形式 択一選択問題・複数選択問題 時間 130分 問題数 65問 合格点 720点 受験料 15,000円(税別) なぜ試験を受けたのか？ 先日、企業のモニタリング体制を構築するちょっとした実務案件を経験させていただき、AWSをより深く、体系的に勉強したいと感じたので、資格取得に挑戦しました。 結果どうなったのか？ 合格！！！！ 学習期間：10月6日〜10月12日までの間（7日間） 試験日：10月13日 学習時間：42時間 なぜ学習期間が１週間なのか？ エンジニアに転職したいという目標のもと、きちんと計画的に勉強ができる人間であることを少しでも証明したいと思い、１週間という短期間で受験することにしました。 この１週間という期間は、現役エンジニアの方から助言を頂き、自分のスキル感と平均的なSAAの資格取得までの期間を総合的に勘案し、実務経験がある人なら２週間程度で取得できるという試算をいただいた上で、設定した学習期間です。 試験合格までの道 1 戦略立案 まず、短期間で合格をするために、最短ルートで合格まで突き抜ける方法を探すことにしました。 この資格は情報が溢れており、たくさんの方が合格のためのノウハウを発信してくれていました。 その情報を集めて、自分のスキル感と再現性を考慮し、自分なりに突破方法を考えました。 その勉強方法は結論から申しますと、徹底的に問題を解く！！これに尽きます。 学習した７日間で私は、合計９４０問の問題を解きました。 ７日間学習に費やすために、まずは半日かけて学習計画を立案しており、情報源は次のとおりです。 【最速】既婚子持ち社会人のクラウド初心者でも、1ヶ月半でAWS資格11冠制覇できる方法 AWS認定11冠制覇したのでオススメの勉強法などをまとめてみる GW11連休を利用してAWS認定6冠を達成しての振り返り これらの情報源を元に自分なりに最短の勉強方法をまとめたところ、 問題をひたすら解く  Udemy と AWSWeb問題集 が2強で、AWSWeb問題集を推しているのが多い  AWSWeb問題集推しの理由：解答に公式ドキュメントへのリンクがあり、間違った問題については公式のどこを読むべきかわかるので効率的に学ことができる 問題を解いて、よく分からない、聞いたことがないサービスについては、公式を見る 参考の公式はブラックベルト 模擬試験を受けて、試験慣れする このような感じでした。 参考書から読みだしたら当然、時間が足りないので、実践で知識も養う！分からなければ、そこだけインプットする！ これが最短の勉強方法とのことでした。 2 学習開始 問題を解きまくって、試験を突破する。 どのような問題集を選ぶのか、最初の戦略立案で、AWSWeb問題集推しが多かったので、私もその問題集を購入することにしました。 実際に勉強してみたところ、AWSの各種試験別に問題が用意されており、SAA試験の場合だと、1000問以上用意されていました。 私は、この問題集を購入（月額制）して、問題を解いていきました。 だいたい7問で1セクションになっていて、ネットで紹介されていたとおり、問題ごとに解説もついており、根拠となる公式のリンクも貼ってありました。 学習２日目の転機 1日目、2日目はこの問題集を解いていたのですが、2日目に、「これはなかなか前に進まない」「効率的ではない気がする」という違和感に気づきました。 その理由は、解説がきちんと載っているのですが、その解説が自分には分かりにくかったからです。 公式のリンク先を参照しても、公式も当然分かりにくいのです。 その結果、一つ一つの問題の理解に時間がかかり、また、全体の問題量が多すぎて、試験までにやりきった感を味わえないと思いました。 また、問題形式が実践と異なっている点も気がかりでした。 ４〜５択の選択問題が多い試験にも関わらず、２択問題が結構あり、私は時間がない中で、選択肢を見るだけでも勉強になるので、問題の形式が違うのは嫌でした。 極めつけは、解説内容をコピペできない仕組みになっており、復習のためにNotionにメモを残したかったので、いちいち自分で１から入力しないといけない状況がとても非効率に感じました。 そこで、２日目の途中で方針を転換することにしたのです。 良質な問題集との出会い　AWS CloudTech SAA試験の良質な問題集を探すため、再度情報を集めました。 欲しい問題集の軸は 解説が分かりやすいこと 問題数がそこそこあること 基本を無視した最短合格を目指すことにフルコミットしていること この軸を満たす問題集を探しました。 すると、見つけました。これです！完全無料(2021/10/12現在)の自分にとって最高の問題集です。 AWS CloudTech こちらのリンク先で、会員登録すると、無料でSAA試験用の問題集２００問を解くことができます。 勉強方法についてもyoutube動画で無料配信してくれています。 この勉強方法は実にシンプルで分かりやすく具体的に紹介してくれています。 勉強方法をまとめると、 200問ある問題を10問づつ解いていく 10問終わったら次に行かずにもう一回同じ10問を解いていく ２回同じ10問を解いたら、次の10問をやり、２回やったらまた戻る、２歩進んで１歩下がるみたいな感じです やった箇所や間違った箇所をスプレッドシートに記録していく 200問を試験日までに全体で５回繰り返す といった感じです。 ある程度まとまった問題を短期間で繰り返して、問題文ごと覚えてしまうくらいやるという勉強方法でした。 これが正解でした。実際の学習記録です。 一番良かったのが、私にとって解説がとてもわかり易かったことです。変な英訳みたいな解説ではなく、作成者が丁寧に解説を作成された感じが伝わって来ました。 また、ある程度まとまった問題集を早い段階でまず一通りでき、安心感を得ることができるという点でも、問題数が丁度よく設定されています。その安心感で、学習がはかどりました。 そして、繰り返しの演習で、問題の傾向や回答の傾向、いわゆる試験問題を解くためのテクニックが身についていき、少しづつ知識も養われいきました。 CloudTechでは動画でAWSを学ぶことができ、無料範囲でも一部閲覧することができる講義動画があるのですが、それがまた分かりやすかったです。 ステートフルとステートレスの違い、ACLとセキュリティグループの違い等をイメージしやすいように噛み砕いて図で説明してくれています。とても頭に入りやすかったです。 この結果、勉強方法が確立しました。(3日目) 問題を繰り返し解き、解説を読んでもよく分からないものは分かりやすい動画を見て学ぶ この方法です。 また、先ほどの画像をご覧いただきたいのですが、CloudTechで紹介されていた方法は、全体を５回繰り返すというものでしたが、私は時間の都合上、4回目以降は間違えた箇所だけやりました。 問題を解いてみて、自分の理解が至らない箇所を重点的に繰り返し、さらに効率的により少ない勉強で試験に臨みました。 目標を定めて、計画をたて、実際にやってみて、試行錯誤して改良を重ね、最良のスタイルを確立するのが大切だと思いました。 インプット用の動画 このAWSCloudTechの他に、私はインプット用にUdemyの講座を購入しました。 AWSCloudTechの無料枠では試験範囲を全て網羅できず、動画で視覚的に勉強したかったからです。 通勤中や仕事の合間、家事の手伝いをしながらでも勉強できるように動画での勉強が必要でした。 Udemyで購入した講座はこちらです。 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） この講座も自分的には当たりでした。 AWSサービスの解説だけではなく、前提として知っておかないといけない知識の講義や実際のAWSサービス利用方法をハンズオン形式でやってくれており、視覚的にざっくり理解することができました。 「見る」という単純な作業で、場所を選ばず、どこでも勉強できて、更には思考を使わず、なんとなくでも理解できるものです。 この講義は全体数が多かったので、私は試験までに全部は見ておらず、全体の30％位を見た程度ですが、とても有益なものでした。 私はこの講義を全てダウンロードし、1.5倍速で隙間時間にどこでも見れるようにして、特に知らないAWSサービスの概要動画をざっと見ることで薄い知識を得て、問題で必要なとこだけ深ぼるスタイルで知識を広げていきました。 ３ 模擬試験 学習５日目（問題数７００問）と７日目（問題数８５０問）に模擬試験を行いました。 先ほどご紹介したUdemy講座の巻末には３回分の模試がついており、本番試験よりも少し難しいくらいの難易度の問題が掲載されています。 私は１回目と２回目のみを２回づつ実施し、本番試験に臨みました。 １回目の試験は正答率５８％、２回目の試験は正答率６０％で、正直試験に合格する気がしませんでした。 SAA試験は自分にはとても難しく感じる試験で、もっと学習期間が必要だと感じたのですが、もはや自分を信じてやり続けるしか道はありませんでした。 模擬試験で間違えた問題はしっかり復習し、解説を読んで、試験日まで問題演習を繰り返しました。 ４ 試験当日 試験当日、私は「自宅受験」を選択し、試験時間ぎりぎりまで問題を解き続けました。 いざ、試験を始めてみると、肌感ですが、自信を持って回答できたのは、全体の４割くらいと思います。 しかし、まったく知らないサービスの問題でも出題の意図と出題者が欲している回答がなんとなく分かる問題が多く、予測で２択まで絞れるものが多かったです。 これはおそらく、問題を繰り返し解くという勉強方法のおかげで見えてきた問題の傾向から回答をなんとなく予測できるようになっていたのではないかと思います。 何はともあれ結果、合格できました。 試験時間については十分あり試験時間に追われるという試験はありません。 余裕を持って試験問題に臨むことができます。 結果的になんとか合格できたのですが、前述のとおり、自信を持って回答できた選択肢は少ないです。 なんとなくで正解した問題が多かったのですが、そのなんとなくは繰り返し解いた問題と薄く広い知識で得た結果なのではないかと思います。あと、たぶん運も味方してくれたと思います ５ 最後に 長々と記事をご覧いただきありがとうございました。 「資格持ってても、実務はできない」というお話はよく聞きます。私もそうだと感じています。 ただ、実際に勉強してみて、AWS認定試験について感じたことは、実務を効率的に習得するのにとても役立つものではないかと感じました。 具体的には、AWSサービスにはどういったものがあるのか、ソリューション作成時の考え方の原則、この問題にはこのサービスを検討みたいな型？を体系的にできたことで、その後の実際に手を動かして実力をつけていくという時にとても役立つのではないかと感じました。 SAA試験の勉強をした後に、先日挑戦させていただいた実務案件をやっていたら、また別のソリューションが提案できただろうなと感じることができ、そういった意味でも、この資格勉強は自分にとって意味があるものだと感じました。 これで絶対受かるという勉強方法ではないですが、この挑戦がどなたかの参考になれば幸いです。 また、7日間、自分が家事・育児ほぼ放棄した状態で応援してくれた家族と一緒に勉強してくれている勉強仲間たち（誰だ？）に感謝申し上げます。 どうもありがとうございました！！

試験を受けたのは何者なのか？ エンジニア未経験の文系大学出身の公務員　33歳 独学で学んだVBAによる業務改善がきっかけで、プログラミングと出会い、エンジニア転職を目指す 新卒後、VBAと出会う(32歳)まで仕事やプライベートでプログラミングに触れたことがない素人 体育会系のノリが好きで、パソコンとは縁もゆかりもない１児の父親 AWS歴　 実務案件に挑戦した42日間　実務案件詳細記事はこちら SAA試験について簡単に AWS公式の受験対象者について AWS 認定ソリューションアーキテクト – アソシエイトは、AWS における、可用性があり、コスト効率が高く、高耐障害性で、スケーラブルな分散システムの設計に関する 1 年以上の実務経験を持つ方を対象としています。 形式 択一選択問題・複数選択問題 時間 130分 問題数 65問 合格点 720点 受験料 15,000円(税別) なぜ試験を受けたのか？ 先日、企業のモニタリング体制を構築するちょっとした実務案件を経験させていただき、AWSをより深く、体系的に勉強したいと感じたので、資格取得に挑戦しました。 結果どうなったのか？ 合格！！！！ 学習期間：10月6日〜10月12日までの間（7日間） 試験日：10月13日 学習時間：42時間 なぜ学習期間が１週間なのか？ エンジニアに転職したいという目標のもと、きちんと計画的に勉強ができる人間であることを少しでも証明したいと思い、１週間という短期間で受験することにしました。 この１週間という期間は、現役エンジニアの方から助言を頂き、自分のスキル感と平均的なSAAの資格取得までの期間を総合的に勘案し、実務経験がある人なら２週間程度で取得できるという試算をいただいた上で、設定した学習期間です。 試験合格までの道 1 戦略立案 まず、短期間で合格をするために、最短ルートで合格まで突き抜ける方法を探すことにしました。 この資格は情報が溢れており、たくさんの方が合格のためのノウハウを発信してくれていました。 その情報を集めて、自分のスキル感と再現性を考慮し、自分なりに突破方法を考えました。 その勉強方法は結論から申しますと、徹底的に問題を解く！！これに尽きます。 学習した７日間で私は、合計９４０問の問題を解きました。 ７日間学習に費やすために、まずは半日かけて学習計画を立案しており、情報源は次のとおりです。 【最速】既婚子持ち社会人のクラウド初心者でも、1ヶ月半でAWS資格11冠制覇できる方法 AWS認定11冠制覇したのでオススメの勉強法などをまとめてみる GW11連休を利用してAWS認定6冠を達成しての振り返り これらの情報源を元に自分なりに最短の勉強方法をまとめたところ、 問題をひたすら解く  Udemy と AWSWeb問題集 が2強で、AWSWeb問題集を推しているのが多い  AWSWeb問題集推しの理由：解答に公式ドキュメントへのリンクがあり、間違った問題については公式のどこを読むべきかわかるので効率的に学ことができる 問題を解いて、よく分からない、聞いたことがないサービスについては、公式を見る 参考の公式はブラックベルト 模擬試験を受けて、試験慣れする このような感じでした。 参考書から読みだしたら当然、時間が足りないので、実践で知識も養う！分からなければ、そこだけインプットする！ これが最短の勉強方法とのことでした。 2 学習開始 問題を解きまくって、試験を突破する。 どのような問題集を選ぶのか、最初の戦略立案で、AWSWeb問題集推しが多かったので、私もその問題集を購入することにしました。 実際に勉強してみたところ、AWSの各種試験別に問題が用意されており、SAA試験の場合だと、1000問以上用意されていました。 私は、この問題集を購入（月額制）して、問題を解いていきました。 だいたい7問で1セクションになっていて、ネットで紹介されていたとおり、問題ごとに解説もついており、根拠となる公式のリンクも貼ってありました。 学習２日目の転機 1日目、2日目はこの問題集を解いていたのですが、2日目に、「これはなかなか前に進まない」「効率的ではない気がする」という違和感に気づきました。 その理由は、解説がきちんと載っているのですが、その解説が自分には分かりにくかったからです。 公式のリンク先を参照しても、公式も当然分かりにくいのです。 その結果、一つ一つの問題の理解に時間がかかり、また、全体の問題量が多すぎて、試験までにやりきった感を味わえないと思いました。 また、問題形式が実践と異なっている点も気がかりでした。 ４〜５択の選択問題が多い試験にも関わらず、２択問題が結構あり、私は時間がない中で、選択肢を見るだけでも勉強になるので、問題の形式が違うのは嫌でした。 極めつけは、解説内容をコピペできない仕組みになっており、復習のためにNotionにメモを残したかったので、いちいち自分で１から入力しないといけない状況がとても非効率に感じました。 そこで、２日目の途中で方針を転換することにしたのです。 良質な問題集との出会い　AWS CloudTech SAA試験の良質な問題集を探すため、再度情報を集めました。 欲しい問題集の軸は 解説が分かりやすいこと 問題数がそこそこあること 基本を無視した最短合格を目指すことにフルコミットしていること この軸を満たす問題集を探しました。 すると、見つけました。これです！完全無料(2021/10/12現在)の自分にとって最高の問題集です。 AWS CloudTech こちらのリンク先で、会員登録すると、無料でSAA試験用の問題集２００問を解くことができます。 勉強方法についてもyoutube動画で無料配信してくれています。 この勉強方法は実にシンプルで分かりやすく具体的に紹介してくれています。 勉強方法をまとめると、 200問ある問題を10問づつ解いていく 10問終わったら次に行かずにもう一回同じ10問を解いていく ２回同じ10問を解いたら、次の10問をやり、２回やったらまた戻る、２歩進んで１歩下がるみたいな感じです やった箇所や間違った箇所をスプレッドシートに記録していく 200問を試験日までに全体で５回繰り返す といった感じです。 ある程度まとまった問題を短期間で繰り返して、問題文ごと覚えてしまうくらいやるという勉強方法でした。 これが正解でした。実際の学習記録です。 一番良かったのが、私にとって解説がとてもわかり易かったことです。変な英訳みたいな解説ではなく、作成者が丁寧に解説を作成された感じが伝わって来ました。 また、ある程度まとまった問題集を早い段階でまず一通りでき、安心感を得ることができるという点でも、問題数が丁度よく設定されています。その安心感で、学習がはかどりました。 そして、繰り返しの演習で、問題の傾向や回答の傾向、いわゆる試験問題を解くためのテクニックが身についていき、少しづつ知識も養われいきました。 CloudTechでは動画でAWSを学ぶことができ、無料範囲でも一部閲覧することができる講義動画があるのですが、それがまた分かりやすかったです。 ステートフルとステートレスの違い、ACLとセキュリティグループの違い等をイメージしやすいように噛み砕いて図で説明してくれています。とても頭に入りやすかったです。 この結果、勉強方法が確立しました。(3日目) 問題を繰り返し解き、解説を読んでもよく分からないものは分かりやすい動画を見て学ぶ この方法です。 また、先ほどの画像をご覧いただきたいのですが、CloudTechで紹介されていた方法は、全体を５回繰り返すというものでしたが、私は時間の都合上、4回目以降は間違えた箇所だけやりました。 問題を解いてみて、自分の理解が至らない箇所を重点的に繰り返し、さらに効率的により少ない勉強で試験に臨みました。 目標を定めて、計画をたて、実際にやってみて、試行錯誤して改良を重ね、最良のスタイルを確立するのが大切だと思いました。 インプット用の動画 このAWSCloudTechの他に、私はインプット用にUdemyの講座を購入しました。 AWSCloudTechの無料枠では試験範囲を全て網羅できず、動画で視覚的に勉強したかったからです。 通勤中や仕事の合間、家事の手伝いをしながらでも勉強できるように動画での勉強が必要でした。 Udemyで購入した講座はこちらです。 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） この講座も自分的には当たりでした。 AWSサービスの解説だけではなく、前提として知っておかないといけない知識の講義や実際のAWSサービス利用方法をハンズオン形式でやってくれており、視覚的にざっくり理解することができました。 「見る」という単純な作業で、場所を選ばず、どこでも勉強できて、更には思考を使わず、なんとなくでも理解できるものです。 この講義は全体数が多かったので、私は試験までに全部は見ておらず、全体の30％位を見た程度ですが、とても有益なものでした。 私はこの講義を全てダウンロードし、1.5倍速で隙間時間にどこでも見れるようにして、特に知らないAWSサービスの概要動画をざっと見ることで薄い知識を得て、問題で必要なとこだけ深ぼるスタイルで知識を広げていきました。 ３ 模擬試験 学習５日目（問題数７００問）と７日目（問題数８５０問）に模擬試験を行いました。 先ほどご紹介したUdemy講座の巻末には３回分の模試がついており、本番試験よりも少し難しいくらいの難易度の問題が掲載されています。 私は１回目と２回目のみを２回づつ実施し、本番試験に臨みました。 １回目の試験は正答率５８％、２回目の試験は正答率６０％で、正直試験に合格する気がしませんでした。 SAA試験は自分にはとても難しく感じる試験で、もっと学習期間が必要だと感じたのですが、もはや自分を信じてやり続けるしか道はありませんでした。 模擬試験で間違えた問題はしっかり復習し、解説を読んで、試験日まで問題演習を繰り返しました。 試験当日 試験当日、私は「自宅受験」を選択し、試験時間ぎりぎりまで問題を解き続けました。 いざ、試験を始めてみると、肌感ですが、自信を持って回答できたのは、全体の４割くらいと思います。 しかし、まったく知らないサービスの問題でも出題の意図と出題者が欲している回答がなんとなく分かる問題が多く、予測で２択まで絞れるものが多かったです。 これはおそらく、問題を繰り返し解くという勉強方法のおかげで見えてきた問題の傾向から回答をなんとなく予測できるようになっていたのではないかと思います。 何はともあれ結果、合格できました。 試験時間については十分あり試験時間に追われるという試験はありません。 余裕を持って試験問題に臨むことができます。 結果的になんとか合格できたのですが、前述のとおり、自信を持って回答できた選択肢は少ないです。 なんとなくで正解した問題が多かったのですが、そのなんとなくは繰り返し解いた問題と薄く広い知識で得た結果なのではないかと思います。あと、たぶん運も味方してくれたと思います 最後に 長々と記事をご覧いただきありがとうございました。 「資格持ってても、実務はできない」というお話はよく聞きます。私もそうだと感じています。 ただ、実際に勉強してみて、AWS認定試験について感じたことは、実務を効率的に習得するのにとても役立つものではないかと感じました。 具体的には、AWSサービスにはどういったものがあるのか、ソリューション作成時の考え方の原則、この問題にはこのサービスを検討みたいな型？を体系的にできたことで、その後の実際に手を動かして実力をつけていくという時にとても役立つのではないかと感じました。 SAA試験の勉強をした後に、先日挑戦させていただいた実務案件をやっていたら、また別のソリューションが提案できただろうなと感じることができ、そういった意味でも、この資格勉強は自分にとって意味があるものだと感じました。 これで絶対受かるという勉強方法ではないですが、この挑戦がどなたかの参考になれば幸いです。 また、7日間、自分が家事・育児ほぼ放棄した状態で応援してくれた家族と一緒に勉強してくれている勉強仲間たち（誰だ？）に感謝申し上げます。 どうもありがとうございました！！

やりたいこと TerraformでまとめてIAMユーザーをバーッと作り、ユーザーグループへバスンと放り込んで大勝利！? きっかけ アカウントの払い出しや棚卸しを安全かつ楽に実施したい → 手始めにIAMユーザーの作成（とユーザーグループへの追加）をTerraformでやってみる IAMユーザーの数だけTerraformリソース（aws_iam_userとaws_iam_group_membership）が必要になる？やだな〜と思ってましたが、moduleとfor_each/eachを使うとすっきり書けて嬉しかった https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_user https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_group_membership 環境と構成 Terraformのバージョンやファイル構成は下記の通りです ❯ terraform version Terraform v1.0.8 on darwin_amd64 terraform/ 　├ envs/ 　│　└ test/ 　│　　　├ main.tf 　│　　　├ outputs.tf 　│　　　├ variables.tf 　│　　　└ provider.tf 　├ modules/ 　│　└ iam/ 　│　　　├ main.tf 　│　　　├ outputs.tf 　│　　　└ variables.tf 　└ src/ 　　　└ user.yml envs/test/provider.tf terraform { required_providers { aws = { source = "hashicorp/aws" version = "3.62.0" } } } provider "aws" { region = "ap-northeast-1" } 関連リソース ユーザー ここではdevとopsという2つのロール（IAMのロールではない）があると仮定して、各ロールのユーザーを3人ずつ作成します 以下のようなyamlファイルにロールとユーザー名を書きます src/user.yaml dev: - dev_tarou_1st - dev_tarou_2nd - dev_tarou_3rd ops: - ops_hanako_1st - ops_hanako_2nd - ops_hanako_3rd ユーザーグループ 今回は作成済みのユーザーグループへユーザーを追加していきます devロールのユーザーはdev_member_group, opsロールのメンバーはops_member_groupにといった感じで何も考えずぶち込みます envs/test/main.tf locals { users = yamldecode(file("../../src/user.yaml")) dev_users = local.users.dev ops_users = local.users.ops dev_groupname = "dev_member_group" dev_membership_name = "dev_members" ops_groupname = "ops_member_group" ops_membership_name = "ops_members" } module "dev" { source = "../../modules/iam" group_users = toset(local.dev_users) membership_name = local.dev_membership_name groupname = local.dev_groupname } module "ops" { source = "../../modules/iam" group_users = toset(local.ops_users) membership_name = local.ops_membership_name groupname = local.ops_groupname } module/iam/main.tf resource "aws_iam_user" "user" { for_each = var.group_users name = each.value } resource "aws_iam_group_membership" "group_assotiation" { depends_on = [aws_iam_user.user] name = var.membership_name users = var.group_users group = var.groupname } module/iam/variables.tf variable "group_users" {} variable "groupname" {} variable "membership_name" {} ユーザー作成は各ロールのユーザーごとにeachでループさせ、ユーザーグループへの追加はtosetを使ってユーザー名のコレクション(set)を渡します ユーザーがいないとグループ追加がこけるので、depends_onで明示的に依存関係を書きます terraform plan してみます terraform plan実行結果 ❯ terraform plan Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # module.dev.aws_iam_group_membership.group_assotiation will be created + resource "aws_iam_group_membership" "group_assotiation" { + group = "dev_member_group" + id = (known after apply) + name = "dev_members" + users = [ + "dev_tarou_1st", + "dev_tarou_2nd", + "dev_tarou_3rd", ] } # module.dev.aws_iam_user.user["dev_tarou_1st"] will be created + resource "aws_iam_user" "user" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "dev_tarou_1st" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } # module.dev.aws_iam_user.user["dev_tarou_2nd"] will be created + resource "aws_iam_user" "user" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "dev_tarou_2nd" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } # module.dev.aws_iam_user.user["dev_tarou_3rd"] will be created + resource "aws_iam_user" "user" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "dev_tarou_3rd" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } # module.ops.aws_iam_group_membership.group_assotiation will be created + resource "aws_iam_group_membership" "group_assotiation" { + group = "ops_member_group" + id = (known after apply) + name = "ops_members" + users = [ + "ops_hanako_1st", + "ops_hanako_2nd", + "ops_hanako_3rd", ] } # module.ops.aws_iam_user.user["ops_hanako_1st"] will be created + resource "aws_iam_user" "user" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "ops_hanako_1st" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } # module.ops.aws_iam_user.user["ops_hanako_2nd"] will be created + resource "aws_iam_user" "user" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "ops_hanako_2nd" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } # module.ops.aws_iam_user.user["ops_hanako_3rd"] will be created + resource "aws_iam_user" "user" { + arn = (known after apply) + force_destroy = false + id = (known after apply) + name = "ops_hanako_3rd" + path = "/" + tags_all = (known after apply) + unique_id = (known after apply) } Plan: 8 to add, 0 to change, 0 to destroy. 良さそう！！！！！！！！！！applyすっぞ！！！！！！！！！！！！ terraform apply しました ええやん? まとめ やりたかったことができてにっこりです が、初期パスワードの設定などほかにも色々必要なのでたくさん頑張ります

AWS AmplifyでWebアプリを開発していてAWS CodeCommitへのpushをトリガーにデプロイされる、という環境で開発していたのですが、コードの管理はGitHubで行うという機会が有りました。 そのため、GitHub Actionsから任意のタイミングでAWS CodeCommitに同期してデプロイが実行されるという環境を作りたかったので、その時のメモです。 AWS CodeCommit SSHキーのアップロード まずはAWSのIAMコンソールから、CodeCommitのSSHパブリックキーをアップロードして、SSHキーIDを取得します。 GitHubのSecretsにSSHキー情報を登録 GitHubの管理画面で、「Settings」 -> 「Secrets」から、先程取得したSSHキーIDと、SSHパブリックキーに対応するシークレットキーを登録します。 今回は例として、 CODECOMMIT_SSH_KEY_ID にSSHキーID、 CODECOMMIT_SSH_PRIVATE_KEY にシークレットキーを登録しました。 GitHub Actionsを設定 下記のコードを、GitHub Actionsのワークフローとして登録します。 target_repo_url には、CodeCommitのリポジトリのURLを指定してください。 name: "Deploy" on: [ workflow_dispatch ] jobs: build: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v2 with: fetch-depth: 0 - name: Push to AWS CodeCommit uses: pixta-dev/repository-mirroring-action@v1 with: target_repo_url: ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/hoge ssh_private_key: ${{ secrets.CODECOMMIT_SSH_PRIVATE_KEY }} ssh_username: ${{ secrets.CODECOMMIT_SSH_KEY_ID }} 以上でGitHub Actions実行時にCodeCommitにリポジトリが同期されます。 意外と簡単ですね！

AWS AmplifyでWebアプリを開発していてAWS CodeCommitへのpushをトリガーにデプロイされる、という環境で開発していたのですが、コードの管理はGitHubで行うという機会が有りました。 そのため、GitHub Actionsから任意のタイミングでAWS CodeCommitに同期してデプロイが実行されるという環境を作りたかったので、その時のメモです。 AWS CodeCommit SSHキーのアップロード まずはAWSのIAMコンソールから、CodeCommitのSSHパブリックキーをアップロードして、SSHキーIDを取得します。 GitHubのSecretsにSSHキー情報を登録 GitHubの管理画面で、「Settings」 -> 「Secrets」から、先程取得したSSHキーIDと、SSHパブリックキーに対応するシークレットキーを登録します。 今回は例として、 CODECOMMIT_SSH_KEY_ID にSSHキーID、 CODECOMMIT_SSH_PRIVATE_KEY にシークレットキーを登録しました。 GitHub Actionsを設定 下記のコードを、GitHub Actionsのワークフローとして登録します。 target_repo_url には、CodeCommitのリポジトリのURLを指定してください。 name: "Deploy" on: [ workflow_dispatch ] jobs: build: runs-on: ubuntu-latest timeout-minutes: 5 steps: - name: Checkout uses: actions/checkout@v2 with: fetch-depth: 0 - name: Push to AWS CodeCommit uses: pixta-dev/repository-mirroring-action@v1 with: target_repo_url: ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/hoge ssh_private_key: ${{ secrets.CODECOMMIT_SSH_PRIVATE_KEY }} ssh_username: ${{ secrets.CODECOMMIT_SSH_KEY_ID }} 以上でGitHub Actions実行時にCodeCommitにリポジトリが同期されます。 意外と簡単ですね！

今回はCloudFormationでLambdaを触ってみるということで、Slackに通知を送信するLambda関数を構築していきたいと思います。 調べてみたところ、Lambdaを構築する場合はCloudFormationの AWS::Serverless というマクロ機能を利用するみたいです。 AWS::Serverless変換 マクロを利用すると「AWS SAM 構文」なるものでLambdaを定義できるようになり、 aws cloudformation package コマンド実行時に、通常のCloudFormationテンプレートに展開されます。 マクロ機能を利用するには、テンプレート内で下記のように宣言します。 template.yml Transform: AWS::Serverless-2016-10-31 SlackのWebhook URLを取得する Slack通知を行うためのWebhookURLを取得します。 Slack での Incoming Webhook の利用 1. 「アプリを追加する」から Incoming Webhookを追加 2. 投稿したいチャンネルを選択し、インテグレーションの追加をクリック 3. Webhook URLをコピー テンプレートの実装 ディレクトリ構成 - project-notify-slack.yml - src/ - lambda_function.py 1. CloudFormationテンプレート実装 下記3つのリソースを作成します Lambda発火の起点となるトピック LambdaのDLQ用トピック Slackに通知を送信するLambda AWS::Serverless::Function project-notify-slack.yml AWSTemplateFormatVersion: "2010-09-09" Transform: AWS::Serverless-2016-10-31 Description: Slack notification app Parameters: SlackWebhookUrl: Type: String SlackChannel: Type: String Email: Type: String Outputs: SlackNotifySnsTopicArn: Value: !Ref SlackNotifyTopic Resources: # Lambda発火の起点となるトピック # https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-sns-topic.html SlackNotifyTopic: Type: AWS::SNS::Topic Properties: TopicName: !Sub ${AWS::StackName}-topic-notify # lambdaのDLQ用トピック # https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-sns-topic.html DlqTopic: Type: AWS::SNS::Topic Properties: TopicName: !Sub ${AWS::StackName}-topic-dlq # https://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html Subscription: - Endpoint: !Ref Email Protocol: email # Slackに通知を送信するLambda # https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html SlackNotifyFunction: Type: AWS::Serverless::Function Properties: FunctionName: !Sub ${AWS::StackName}-function CodeUri: ./src # lambdaのエントリーポイント(ファイル名.関数名) Handler: lambda_function.lambda_handler Runtime: python3.8 MemorySize: 128 Timeout: 180 # 環境変数 Environment: Variables: SLACK_WEBHOOK_URL: !Ref SlackWebhookUrl SLACK_CHANNEL: !Ref SlackChannel # Lambdaの処理が規定回数以上失敗した場合の通知先 # https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-deadletterqueue.html DeadLetterQueue: Type: SNS TargetArn: !Ref DlqTopic # 関数実行の起点となるイベントソースを定義 # https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-eventsource.html Events: Rule: Type: SNS Properties: Topic: !Ref SlackNotifyTopic 2. Lambda関数の実装 Slackに通知を送信する関数を実装します。（公式のコピペです) /src/lambda_function.py #!/usr/bin/python3.8 import urllib3 import json import os http = urllib3.PoolManager() def lambda_handler(event, context): url = os.getenv("SLACK_WEBHOOK_URL") channel = os.getenv("SLACK_CHANNEL") print("url={}, channel={}".format(url, channel)) msg = { "channel": channel, "text": event['Records'][0]['Sns']['Message'], "icon_emoji": "" } encoded_msg = json.dumps(msg).encode('utf-8') resp = http.request('POST',url, body=encoded_msg) print({ "message": event['Records'][0]['Sns']['Message'], "status_code": resp.status, "response": resp.data }) デプロイ aws cloudformation package コマンドで、AWS SAM形式のテンプレート(マクロ）を展開します。 デプロイに必要な資材をs3にアップロードする必要があるので、適当なバケットを作ってオプションに渡します。 # lambdaのデプロイ資材をアップロードするバケット S3_BUCKET="sample-bucket" # デプロイ資材の格納パス S3_PREFIX="path/to/package" # lambda関数をパッケージ # --output-template-file に指定したファイル名に展開後のテンプレートが保存されます。 aws cloudformation package \ --region "ap-northeast-1" \ --profile "default" \ --template-file "project-notify-slack.yml" \ --output-template-file "project-notify-slack-package.yml" \ --s3-bucket "${S3_BUCKET}" \ --s3-prefix "${S3_PREFIX}" 展開されたテンプレートをデプロイします。 # スタック名任意 STACK_NAME="sample-stack" # 先ほど取得したWebhook URLを定義 SLACK_WEBHOOK_URL="https://hooks.slack.com/services/xxxxxxxxx/YYYYYYYYYYY/ZZZZZZZZZZZ" # 通知を飛ばしたいチャンネル名を指定 SLACK_CHANNEL="#test-midorikawa" # lambda処理失敗時に通知を飛ばすメールアドレスを指定 EMAIL="hogehoge@example.com" # デプロイ aws cloudformation deploy \ --region "ap-northeast-1" \ --profile "default" \ --stack-name "${STACK_NAME}" \ --template-file "project-notify-slack-package.yml" \ --capabilities CAPABILITY_NAMED_IAM \ --parameter-overrides \ SlackWebhookUrl="${SLACK_WEBHOOK_URL}" \ SlackChannel="${SLACK_CHANNEL}" \ Email="${EMAIL}" 動作確認 CLIからトピックにpublishしてSlackに通知が送信されるか確認します。 # TopicArnを確認 TOPIC_ARN=$(aws cloudformation describe-stacks --stack-name $STACK_NAME | jq '.Stacks[].Outputs[]') # メッセージを送信 aws sns publish --topic-arn "${TOPIC_ARN}" --subject testSubject --message testMessage 参考

目的 AWS SAM を使って Go 言語でサーバーレスアプリケーションを開発するための、環境構築の手順をまとめます。個人的な備忘録を兼ねているため、必須ではない細かな設定なども記載しています。Lambda でサーバーレスアプリケーションの開発をはじめようと思っている方の参考になれば幸いです。 当記事に含まれる内容 当記事に含まれる内容は下記の通りです。ソフトウェアのインストールなどは既にわかりやすい記事があるので、そのリンクを貼っています。 Hello World アプリケーションについて WSL2 の設定 Docker の設定 AWS CLI の設定 Session Manager プラグインの設定 SAM と Go のインストール Ubuntu の環境変数設定の自動化 VSCode の設定 SAM プロジェクトの新規作成 SAM プロジェクトのデプロイ AWS コンソールから各サービスを確認 Hello World アプリケーションについて Hello World アプリケーションは、SAM プロジェクトを新規作成するときに便利なサンプルプロジェクトです。クライアントが API Gateway のエンドポイントにリクエストすると、「Hello, xxx.xxx.xxx.xxx（Lambda の IP アドレス）」とレスポンスを返す、シンプルなアプリです。はじめは、このアプリに変更を加えながらオリジナルのサーバーレスアプリケーションを開発していくと、楽だと思います。 Hello World アプリケーションの AWS 構成 構成図上のサービスの概要をひと言でまとめました。詳細が知りたい方はサービス名のリンクを参照してください。 Amazon API Gateway：API の開発や公開などが簡単に行えるサービスです。 AWS Lambda：サーバーレスで小さなプログラムを実行できるサービスです。 Amazon CloudWatch Logs：AWS リソースのログをモニタリングできるサービスです。 WSL2 の設定 WSL2 (Windows Subsystem for Linux 2) は、Windows 10 上で Linux を動作させるための仕組みです。サーバーレスアプリケーションをローカル環境でテストする際に、SAM は Lambda ファンクションを実行するための Docker コンテナを立ち上げます。Windows 上で Docker を利用するとエラーにハマることが多いので、WSL2 上に環境構築しています。WSL1 だと裏で動いているのは Windows なので、Docker をはじめとする一部のソフトウェアでは不具合が生じます。そのため WSL2 を利用しています。 WSL2 のインストール インストールがまだの方は、下記のサイトなどを参考にインストールをお願いします。 WSL のインストール インストールが終わったら PowerShell を開き、 wsl --list --verbose コマンドで WSL のバージョンを確認してください。下記のように VERSION が 2 と表示されていれば大丈夫です。 [win] wsl --list --verbose NAME STATE VERSION * Ubuntu Running 2 docker-desktop Running 2 docker-desktop-data Running 2 WSL に Windows の PATH を引き継がないように設定する WSL はそのまま利用すると Windows の環境変数の PATH を引き継ぎます。WSL 上の /etc/wsl.conf ファイルを編集すると、Windows の PATH を引き継がないように設定できます。 # WSL 上の /etc/wsl.conf ファイルを編集 $ sudo vim /etc/wsl.conf # wsl.conf がない場合は新規作成 $ sudo touch /etc/wsl.conf wsl.conf に下記の文言を追記してください。 [interop] appendWindowsPath = false 以上で WSL の設定は完了です。 参考サイト：WSLでWindowsのPATHを引き継がないようにする方法 Docker の設定 1. WSL に Docker と docker-compose をインストール Docker の公式サイトなどを参考に、WSL に Docker や docker-compose をインストールします。 Docker のインストール docker-compose のインストール Windows に Docker Desktop をインストール Windows に Docker Desktop をインストールして、Docker Desktop を WSL バックエンドで使えるように設定します。下記のサイトなどを参考に、Docker Desktop のインストールをお願いします。 Windows に Docker Desktop をインストール インストールが完了したら、Dokcer Desktop を開いて以下の設定を行います。 Settigs > General を開き、Expose daemon on tcp://localhost:2375 without TLS にチェックをつける Apply & Restart を実行する PC を再起動する ※一度再起動しないと VSCode から WSL に接続した際に Dokcer を起動できないようです。 以上で Docker の設定は完了です。 AWS CLI の設定 AWS CLI は AWS をコマンドラインで操作・管理するためのツールです。インストールがまだの方は、下記のサイトなどを参考にインストールをお願います。 AWS CLI をインストール (LINUX) インストールが完了したら aws configure コマンドを実行して、AWS Access Key ID、AWS Secret Access Key、Default region name、Default output format を入力します。 $ aws configure AWS Access Key ID [None]: XXXXXXXXXX AWS Secret Access Key [None]: XXXXXXXXXX Default region name [None]: ap-northeast-1 Default output format [None]: json 設定が完了したら、aws sts get-caller-identity コマンドで IAM ユーザーアクセス権があることを確認してみます。 $ aws sts get-caller-identity { "UserId": "XXXXXXXXXX", "Account": "XXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXX:user/XXXXXXXXXX" } 以上で AWS CLI の設定は完了です。 Session Manager プラグインの設定 Session Manager プラグインをインストールしておくと、プライベートサブネットの EC2 に SSH で接続したり、SCP で EC2 - ローカル間でファイル転送ができるようになり便利です。興味のある方は、下記のサイトなどを参考にインストールしてみてください。 Session Manager plugin をインストール (LINUX) インストールにあたり WSL の CPU 情報が不明な場合は、sudo lshw -class processor コマンドで確認できます。 $ sudo lshw -class processor [sudo] password for funaki: *-cpu product: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz vendor: Intel Corp. physical id: 1 bus info: cpu@0 width: 64 bits capabilities: ... インストールが完了したら、～.ssh\config にある SSH 設定ファイルに下記の文言を追記して、Session Manager を通した SSH 接続を有効にします。 # SSH over Session Manager host i-* mi-* ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" 以上で Session Manager プラグイン の設定は完了です。 プライベートサブネットにある EC2 に SSH や SCP でアクセスする方法について、下記の記事にまとめています。興味のある方はぜひご覧ください。 AWS CLIを使用してEC2にSSHやSCPでアクセスする SAM と Go のインストール 続いて、SAM と Go のインストールです。SAM をインストールする前に Python のパッケージマネージャをインストールする必要があります。以下の順番でコマンドを実行してください。 ※Delve という Go のデバッグツールもインストールしていますが、インストールしなくても問題ありません。 1. sudo apt update # Ubuntu のローカルキャッシュ済みパッケージ一覧を更新 2. sudo apt install python3-pip # SAM をインストールするため、Python のパッケージマネージャをインストール 3. sudo pip3 install aws-sam-cli # SAM をインストール 4. sudo apt install golang-go # Go をインストール 5. go install github.com/go-delve/delve/cmd/dlv@latest # Go のリモートデバッグ用に Delve をインストール ※2021年7月の SAM CLI の重要なアップグレードにより、バージョン 1.25 以上へのアップデートが必要になりました。もし古いバージョンをお使いでしたら、下記のコマンドで SAM CLI をアップデートしてください。 sudo pip3 install -U aws-sam-cli # SAM CLI をアップデート 下記のコマンドで Python、SAM、Go がインストールされていることを確認できます。 $ pip3 --version pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8) $ sam --version SAM CLI, version 1.21.1 $ go version go version go1.13.8 linux/amd64 $ dlv version Delve Debugger Version: 1.6.0 Build: $Id: 8cc9751909843dd55a46e8ea2a561544f70db34d 以上で SAM と Go のインストールは完了です。 Ubuntu の環境変数設定の自動化 export コマンドで GOPATH や PATH などの環境変数を設定しても、Ubuntu ターミナルを閉じると初期化されてしまいます。Ubuntu ターミナルを起動する度に環境変数を設定するのは面倒なので、起動時に環境変数が自動で設定されるよう、下記のコマンドで ~.profile に export コマンドを追記しておきます。 $ cd # HOME ディレクトリに移動 $ sudo echo export GOPATH=$HOME/go >> .profile # GOPATH の設定 $ sudo echo export PATH=$PATH:$GOPATH/bin >> .profile # PATH の設定 ~.profile ファイルに下記の 2 行が追記されていれば設定完了です。 export GOPATH="Path to Go" export PATH="Path to Go"/bin 参考サイト：【Linux】環境変数の確認・設定・削除・永続化について VSCode の設定 Go で開発するときの IDE は VSCode を利用しています。VSCode の設定内容について、備忘録として残しておきます。 1. 拡張機能と依存パッケージをインストール 下記の記事の以下 2 項目を実行します。 VSCodeでGo言語の開発環境を構築する Go言語の拡張機能をインストール 拡張機能の依存パッケージをインストール 以上です。 2. VSCode のフォーマットツールを gofmt に設定 VSCode のフォーマットツールを (1) でインストールした gofmt に設定します。 メニューから File > Preferences > Settings > Extensions > Go > Format Tool の順に開き、gofmt を選択します。 以上です。 gofmt がインストールされているかどうかは、下記のコマンドで確認できます。 $ which gofmt /usr/bin/gofmt 3. VSCode のリントツールを golangci-lint に設定 VSCode のリントツールを (1) でインストールした golangci-lint に設定します。 メニューから file > Preferences > Settings > Extensions > Go > Lint Tool の順に開き、 golangci-lint を選択します。 以上です。 golangci-lint がインストールされているかどうかは、下記のコマンドで確認できます。 $ golangci-lint --version golangci-lint has version 1.33.0 built from b90551c on 2020-11-23T05:15:36Z 4. VSCode から WSL に接続 VSCode から WSL に接続する方法は、下記の記事を参考にしました。 VSCode から WSL に接続する 上記サイトの以下 2 項目を実行します。 Visual Studio Code を WSL へ接続する Ubuntu から Visual Studio Code を起動する 以上です。 SAM プロジェクトの新規作成 ここからは SAM プロジェクトの新規作成に入ります。冒頭で説明した通り、ここでは Hello World アプリケーションを作成していきます。 まず、WSL2 を起動して、サンプルプロジェクトをクローンするディレクトリに移動します。 $ cd /path/to/dir サンプルプロジェクトを作成するにはsam init [OPTION] コマンドを使用します。オプションをつけて sam init --runtime go1.x --name プロジェクト名 として、ランタイムとプロジェクト名を指定します。すると、コマンド入力後にテンプレートについて聞かれるので、(1) の「クイックスタートテンプレート」を選択します。 $ sam init --runtime go1.x --name SamTest Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice: 1 # 1 を選択 使用しているコマンドのオプションの解説です。 オプション 説明 --runtime アプリケーションのランタイムを指定します。言語設定のようなものです。 --name プロジェクトディレクトリに任意の名前をつけることができます。 その他のオプションが知りたい方は、AWS デベロッパーガイド をご参照ください。 次に、パッケージタイプを聞かれるので、(1) の「Zip」を選択します。 What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) 2 - Image (artifact is an image uploaded to an ECR image repository) Package type: 1 # 1 を選択 Cloning from https://github.com/aws/aws-sam-cli-app-templates 最後に、クイックスタートテンプレートの種類を決めます。ここでは、(1) の「Hello World Example」を選択します。 AWS quick start application templates: 1 - Hello World Example 2 - Step Functions Sample App (Stock Trader) Template selection: 1 # 1 を選択 ----------------------- Generating application: ----------------------- Name: SamTest Runtime: go1.x Dependency Manager: mod Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./SamTest/README.md 以上でサンプルプロジェクトが作成されます。 プロジェクトの内容は下記の通りです。 . ├── Makefile <-- 自動ビルドや自動デプロイなどの設定を記載 ├── README.md <-- プロジェクトの説明ファイル ├── hello-world <-- Lambda ファンクションのコードを格納するディレクトリ │ ├── main.go <-- Lambda ファンクションのコード │ └── main_test.go <-- ユニットテスト └── template.yaml <-- SAM テンプレート template.yaml ファイルは SAM テンプレートと呼ばれるもので、CloudFormation を拡張したものになっています。SAM テンプレートのリソースには Lambda ファンクション（AWS::Serverless::Function）しか記載されていませんが、暗黙的に以下のリソースが作成されます。各サービスの当アプリでの役割も簡単に記載しておきます。 Amazon API Gateway：API Gateway が提供するエンドポイントへのリクエストをトリガーに Lambda が起動します。 IAM ロール：Lambda にアタッチされる IAM ロールです。Lambda に各 AWS サービスへのアクセス権を与えます。 Amazon CloudWatch ロググループ：Lambda のログをモニタリングするためのロググループです。 SAM プロジェクトのデプロイ では、サンプルプロジェクトの Hello World アプリケーションを、このまま AWS にデプロイしていきたいと思います。 1. プロファイルの設定 デプロイする前に、デプロイ先の AWS アカウント を確認しておきましょう。僕の場合は、名前付きプロファイル を設定して、プロファイルを切り替えることでデプロイ先を指定しています。 プロファイルを設定済みの方は、aws configure list コマンドで現在使用中のプロファイルを表示できます。 $ aws configure list Name Value Type Location ---- ----- ---- -------- profile Name manual --profile access_key ****************XXXX shared-credentials-file secret_key ****************XXXX shared-credentials-file region ap-northeast-1 config-file ~/.aws/config まだ IAM ユーザーのアクセスキーとシークレットアクセスキーを作成していない方は、下記の記事を参考に作成してください。 AWS ユーザーガイド アクセスキー ID とシークレットアクセスキー プロファイルの設定がまだの方は、aws configure --profile プロファイル名 で設定できます。 $ aws configure # デフォルトのプロファイルを設定 $ aws configure --profile Name # 名前付きプロファイルを設定 2. ビルド デプロイ先の AWS アカウントのプロファイルの設定が完了したら、sam build コマンドでビルドします。 $ sam build Building codeuri: /path/to/project/dir/SamTest/hello-world runtime: go1.x metadata: {} functions: ['HelloWorldFunction'] Running GoModulesBuilder:Build Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke [*] Deploy: sam deploy --guided 以上でビルド完了です。 3. デプロイ はじめてデプロイする場合は、sam deploy --guided コマンドを利用し、スタック名やリージョンなどを指定します。 $ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Not found Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: SamTest AWS Region [ap-northeast-1]: #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y # Yes を選択 #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: Y # Yes を選択 HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y Save arguments to configuration file [Y/n]: # Yes を選択 SAM configuration file [samconfig.toml]: # デフォルトの samconfig.toml で作成 SAM configuration environment [default]: # デフォルトの default で設定 ～省略～ Successfully created/updated stack - SamTest in ap-northeast-1 下記に、質問される内容を記載しておきます。 スタック名：CloudFormation にデプロイするスタックの名前。これはアカウントと地域に固有である必要があります。プロジェクト名から始めるとわかりやすいです。 AWSリージョン：アプリをデプロイする AWS リージョンを指定します。 展開前に変更を確認する：Yes に設定すると、デプロイするときにリソースの変更内容を確認できます。No に設定すると、リソースの変更内容が表示されないまま自動的にデプロイされます。 SAM CLI IAMロールの作成を許可する：AWS SAM テンプレートは、作成された Lambda ファンクションが他の AWS サービスにアクセスするために必要な IAM ロールを作成します。デフォルトでは、最低限必要な権限を持つIAMロールが作成されます。Lambda にアタッチする IAM ロールを自分で作成する場合には、オプションで --capabilities CAPABILITY_NAMED_IAM を指定する必要があります。 引数をsamconfig.tomlに保存：Yes に設定すると、選択した内容がプロジェクト内の samconfig.toml ファイルに保存されます。samconfig.toml を作成しておくと、次回以降のデプロイは sam deploy コマンドだけで実行することが可能です。 質問にひと通り回答したら、ビルドしたプログラムが S3 にアップロードされ、template.taml で定義した AWS リソースが作成されていきます。 "Successfully created/updated stack" というメッセージが表示されたら、デプロイ完了です。 ターミナルに表示されている Outputs に、デプロイされた Lambda ファンクションのエンドポイント（Value）が記載されています。 Key HelloWorldAPI Description API Gateway endpoint URL for Prod environment for First Function Value https://xxxxxxxx ブラウザからエンドポイントにアクセスしてみます。 以上のように表示されれば、デプロイ成功です。 ここから少しずつコードに変更を加えたり、SAM テンプレートに変更を加えたりしていくと、オリジナルのサーバーレスアプリケーションを開発することができます。 AWS コンソールから各サービスを確認 最後に、AWS のコンソールから作成したアプリの各サービスを見てみます。なお、各サービスには自動で名前がつけられていますが、SAM テンプレートを使って任意の名前をつけることができます。 CloudFormation CloudFormation > スタック の順に開くと、sam deploy --guided で指定したスタック名でスタックが作成されていることがわかります。スタック名をクリックすると詳細を確認できます。SAM CLI を使ってデプロイした場合、SAM テンプレートの内容をもとに CloudFormation で各リソースが作成されることがわかると思います。2 回目以降のデプロイでは、このスタックを更新して各リソースに変更を加えていくことができます。 AWS Lambda Lambda > 関数 の順に開くと、新たに Lambda ファンクションが作成されていることがわかります。関数名から詳細を確認できます。 API Gateway API Gateway を開くと、新たに API が作成されていることがわかります。API 名から詳細を確認できます。 CloudWatch ロググループ CloudWatch > ロググループ の順に開くと、新たにロググループが作成されていることがわかります。ロググループ名から Lambda のログファイルを見ることができます。 以上で当記事の内容は終了です。お疲れさまでした！ おわりに 説明が簡単になってしまったところや、今回書ききれなかった内容などは、時間を見つけて修正したり続編の記事などを書いていけたらと思っています。 下記のような内容に興味がある方がいたら、LGTM いただけるとありがたいです。今後の参考にさせていただきます。 SAM テンプレートのおすすめの設定 Makefile のおすすめの設定 SAM を使った開発でのリモートデバッグの方法 Lambda から安全に RDS や Aurora に接続する方法 SQS をトリガーにした Lambda ファンクションの開発 最後までお読みいただき、ありがとうございました！

目的 AWS SAM を使って Go 言語でサーバーレスアプリケーションを開発するための、環境構築の手順をまとめます。個人的な備忘録を兼ねているため、必須ではない細かな設定なども記載しています。Lambda でサーバーレスアプリケーションの開発をはじめようと思っている方の参考になれば幸いです。 当記事に含まれる内容 当記事に含まれる内容は下記の通りです。ソフトウェアのインストールなどは既にわかりやすい記事があるので、そのリンクを貼っています。 Hello World アプリケーションについて WSL2 の設定 Docker の設定 AWS CLI の設定 Session Manager プラグインの設定 SAM と Go のインストール Ubuntu の環境変数設定の自動化 VSCode の設定 SAM プロジェクトの新規作成 SAM プロジェクトのデプロイ AWS コンソールから各サービスを確認 Hello World アプリケーションについて Hello World アプリケーションは、SAM プロジェクトを新規作成するときに便利なサンプルプロジェクトです。クライアントが API Gateway のエンドポイントにリクエストすると、「Hello, xxx.xxx.xxx.xxx（Lambda の IP アドレス）」とレスポンスを返す、シンプルなアプリです。はじめは、このアプリに変更を加えながらオリジナルのサーバーレスアプリケーションを開発していくと、楽だと思います。 Hello World アプリケーションの AWS 構成 構成図上のサービスの概要をひと言でまとめました。詳細が知りたい方はサービス名のリンクを参照してください。 Amazon API Gateway：API の開発や公開などが簡単に行えるサービスです。 AWS Lambda：サーバーレスで小さなプログラムを実行できるサービスです。 Amazon CloudWatch Logs：AWS リソースのログをモニタリングできるサービスです。 WSL2 の設定 WSL2 (Windows Subsystem for Linux 2) は、Windows 10 上で Linux を動作させるための仕組みです。サーバーレスアプリケーションをローカル環境でテストする際に、SAM は Lambda ファンクションを実行するための Docker コンテナを立ち上げます。Windows 上で Docker を利用するとエラーにハマることが多いので、WSL2 上に環境構築しています。WSL1 だと裏で動いているのは Windows なので、Docker をはじめとする一部のソフトウェアでは不具合が生じます。そのため WSL2 を利用しています。 WSL2 のインストール インストールがまだの方は、下記のサイトなどを参考にインストールをお願いします。 WSL のインストール インストールが終わったら PowerShell を開き、 wsl --list --verbose コマンドで WSL のバージョンを確認してください。下記のように VERSION が 2 と表示されていれば大丈夫です。 [win] wsl --list --verbose NAME STATE VERSION * Ubuntu Running 2 docker-desktop Running 2 docker-desktop-data Running 2 WSL に Windows の PATH を引き継がないように設定する WSL はそのまま利用すると Windows の環境変数の PATH を引き継ぎます。WSL 上の /etc/wsl.conf ファイルを編集すると、Windows の PATH を引き継がないように設定できます。 # WSL 上の /etc/wsl.conf ファイルを編集 $ sudo vim /etc/wsl.conf # wsl.conf がない場合は新規作成 $ sudo touch /etc/wsl.conf wsl.conf に下記の文言を追記してください。 [interop] appendWindowsPath = false 以上で WSL の設定は完了です。 参考サイト：WSLでWindowsのPATHを引き継がないようにする方法 Docker の設定 1. WSL に Docker と docker-compose をインストール Docker の公式サイトなどを参考に、WSL に Docker や docker-compose をインストールします。 Docker のインストール docker-compose のインストール Windows に Docker Desktop をインストール Windows に Docker Desktop をインストールして、Docker Desktop を WSL バックエンドで使えるように設定します。下記のサイトなどを参考に、Docker Desktop のインストールをお願いします。 Windows に Docker Desktop をインストール インストールが完了したら、Dokcer Desktop を開いて以下の設定を行います。 Settigs > General を開き、Expose daemon on tcp://localhost:2375 without TLS にチェックをつける Apply & Restart を実行する PC を再起動する ※一度再起動しないと VSCode から WSL に接続した際に Dokcer を起動できないようです。 以上で Docker の設定は完了です。 AWS CLI の設定 AWS CLI は AWS をコマンドラインで操作・管理するためのツールです。インストールがまだの方は、下記のサイトなどを参考にインストールをお願います。 AWS CLI をインストール (LINUX) インストールが完了したら aws configure コマンドを実行して、AWS Access Key ID、AWS Secret Access Key、Default region name、Default output format を入力します。 $ aws configure AWS Access Key ID [None]: XXXXXXXXXX AWS Secret Access Key [None]: XXXXXXXXXX Default region name [None]: ap-northeast-1 Default output format [None]: json 設定が完了したら、aws sts get-caller-identity コマンドで IAM ユーザーアクセス権があることを確認してみます。 $ aws sts get-caller-identity { "UserId": "XXXXXXXXXX", "Account": "XXXXXXXXXX", "Arn": "arn:aws:iam::XXXXXXXXXX:user/XXXXXXXXXX" } 以上で AWS CLI の設定は完了です。 Session Manager プラグインの設定 Session Manager プラグインをインストールしておくと、プライベートサブネットの EC2 に SSH で接続したり、SCP で EC2 - ローカル間でファイル転送ができるようになり便利です。興味のある方は、下記のサイトなどを参考にインストールしてみてください。 Session Manager plugin をインストール (LINUX) インストールにあたり WSL の CPU 情報が不明な場合は、sudo lshw -class processor コマンドで確認できます。 $ sudo lshw -class processor [sudo] password for funaki: *-cpu product: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz vendor: Intel Corp. physical id: 1 bus info: cpu@0 width: 64 bits capabilities: ... インストールが完了したら、～.ssh\config にある SSH 設定ファイルに下記の文言を追記して、Session Manager を通した SSH 接続を有効にします。 # SSH over Session Manager host i-* mi-* ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" 以上で Session Manager プラグイン の設定は完了です。 プライベートサブネットにある EC2 に SSH や SCP でアクセスする方法について、下記の記事にまとめています。興味のある方はぜひご覧ください。 AWS CLIを使用してEC2にSSHやSCPでアクセスする SAM と Go のインストール 続いて、SAM と Go のインストールです。SAM をインストールする前に Python のパッケージマネージャをインストールする必要があります。以下の順番でコマンドを実行してください。 ※Delve という Go のデバッグツールもインストールしていますが、インストールしなくても問題ありません。 1. sudo apt update # Ubuntu のローカルキャッシュ済みパッケージ一覧を更新 2. sudo apt install python3-pip # SAM をインストールするため、Python のパッケージマネージャをインストール 3. sudo pip3 install aws-sam-cli # SAM をインストール 4. sudo apt install golang-go # Go をインストール 5. go install github.com/go-delve/delve/cmd/dlv@latest # Go のリモートデバッグ用に Delve をインストール ※2021年7月の SAM CLI の重要なアップグレードにより、バージョン 1.25 以上へのアップデートが必要になりました。もし古いバージョンをお使いでしたら、下記のコマンドで SAM CLI をアップデートしてください。 sudo pip3 install -U aws-sam-cli # SAM CLI をアップデート 下記のコマンドで Python、SAM、Go がインストールされていることを確認できます。 $ pip3 --version pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8) $ sam --version SAM CLI, version 1.21.1 $ go version go version go1.13.8 linux/amd64 $ dlv version Delve Debugger Version: 1.6.0 Build: $Id: 8cc9751909843dd55a46e8ea2a561544f70db34d 以上で SAM と Go のインストールは完了です。 Ubuntu の環境変数設定の自動化 export コマンドで GOPATH や PATH などの環境変数を設定しても、Ubuntu ターミナルを閉じると初期化されてしまいます。Ubuntu ターミナルを起動する度に環境変数を設定するのは面倒なので、起動時に環境変数が自動で設定されるよう、下記のコマンドで ~.profile に export コマンドを追記しておきます。 $ cd # HOME ディレクトリに移動 $ sudo echo export GOPATH=$HOME/go >> .profile # GOPATH の設定 $ sudo echo export PATH=$PATH:$GOPATH/bin >> .profile # PATH の設定 ~.profile ファイルに下記の 2 行が追記されていれば設定完了です。 export GOPATH="Path to Go" export PATH="Path to Go"/bin 参考サイト：【Linux】環境変数の確認・設定・削除・永続化について VSCode の設定 Go で開発するときの IDE は VSCode を利用しています。VSCode の設定内容について、備忘録として残しておきます。 1. 拡張機能と依存パッケージをインストール 下記の記事の以下 2 項目を実行します。 VSCodeでGo言語の開発環境を構築する Go言語の拡張機能をインストール 拡張機能の依存パッケージをインストール 以上です。 2. VSCode のフォーマットツールを gofmt に設定 VSCode のフォーマットツールを (1) でインストールした gofmt に設定します。 メニューから File > Preferences > Settings > Extensions > Go > Format Tool の順に開き、gofmt を選択します。 以上です。 gofmt がインストールされているかどうかは、下記のコマンドで確認できます。 $ which gofmt /usr/bin/gofmt 3. VSCode のリントツールを golangci-lint に設定 VSCode のリントツールを (1) でインストールした golangci-lint に設定します。 メニューから file > Preferences > Settings > Extensions > Go > Lint Tool の順に開き、 golangci-lint を選択します。 以上です。 golangci-lint がインストールされているかどうかは、下記のコマンドで確認できます。 $ golangci-lint --version golangci-lint has version 1.33.0 built from b90551c on 2020-11-23T05:15:36Z 4. VSCode から WSL に接続 VSCode から WSL に接続する方法は、下記の記事を参考にしました。 VSCode から WSL に接続する 上記サイトの以下 2 項目を実行します。 Visual Studio Code を WSL へ接続する Ubuntu から Visual Studio Code を起動する 以上です。 SAM プロジェクトの新規作成 ここからは SAM プロジェクトの新規作成に入ります。冒頭で説明した通り、ここでは Hello World アプリケーションを作成していきます。 まず、WSL2 を起動して、サンプルプロジェクトをクローンするディレクトリに移動します。 $ cd /path/to/dir サンプルプロジェクトを作成するにはsam init [OPTION] コマンドを使用します。オプションをつけて sam init --runtime go1.x --name プロジェクト名 として、ランタイムとプロジェクト名を指定します。すると、コマンド入力後にテンプレートについて聞かれるので、(1) の「クイックスタートテンプレート」を選択します。 $ sam init --runtime go1.x --name SamTest Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Choice: 1 # 1 を選択 使用しているコマンドのオプションの解説です。 オプション 説明 --runtime アプリケーションのランタイムを指定します。言語設定のようなものです。 --name プロジェクトディレクトリに任意の名前をつけることができます。 その他のオプションが知りたい方は、AWS デベロッパーガイド をご参照ください。 次に、パッケージタイプを聞かれるので、(1) の「Zip」を選択します。 What package type would you like to use? 1 - Zip (artifact is a zip uploaded to S3) 2 - Image (artifact is an image uploaded to an ECR image repository) Package type: 1 # 1 を選択 Cloning from https://github.com/aws/aws-sam-cli-app-templates 最後に、クイックスタートテンプレートの種類を決めます。ここでは、(1) の「Hello World Example」を選択します。 AWS quick start application templates: 1 - Hello World Example 2 - Step Functions Sample App (Stock Trader) Template selection: 1 # 1 を選択 ----------------------- Generating application: ----------------------- Name: SamTest Runtime: go1.x Dependency Manager: mod Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./SamTest/README.md 以上でサンプルプロジェクトが作成されます。 プロジェクトの内容は下記の通りです。 . ├── Makefile <-- 自動ビルドや自動デプロイなどの設定を記載 ├── README.md <-- プロジェクトの説明ファイル ├── hello-world <-- Lambda ファンクションのコードを格納するディレクトリ │ ├── main.go <-- Lambda ファンクションのコード │ └── main_test.go <-- ユニットテスト └── template.yaml <-- SAM テンプレート template.yaml ファイルは SAM テンプレートと呼ばれるもので、CloudFormation を拡張したものになっています。SAM テンプレートのリソースには Lambda ファンクション（AWS::Serverless::Function）しか記載されていませんが、暗黙的に以下のリソースが作成されます。各サービスの当アプリでの役割も簡単に記載しておきます。 Amazon API Gateway：API Gateway が提供するエンドポイントへのリクエストをトリガーに Lambda が起動します。 IAM ロール：Lambda にアタッチされる IAM ロールです。Lambda に各 AWS サービスへのアクセス権を与えます。 Amazon CloudWatch ロググループ：Lambda のログをモニタリングするためのロググループです。 SAM プロジェクトのデプロイ では、サンプルプロジェクトの Hello World アプリケーションを、このまま AWS にデプロイしていきたいと思います。 1. プロファイルの設定 デプロイする前に、デプロイ先の AWS アカウント を確認しておきましょう。僕の場合は、名前付きプロファイル を設定して、プロファイルを切り替えることでデプロイ先を指定しています。 プロファイルを設定済みの方は、aws configure list コマンドで現在使用中のプロファイルを表示できます。 $ aws configure list Name Value Type Location ---- ----- ---- -------- profile Name manual --profile access_key ****************XXXX shared-credentials-file secret_key ****************XXXX shared-credentials-file region ap-northeast-1 config-file ~/.aws/config まだ IAM ユーザーのアクセスキーとシークレットアクセスキーを作成していない方は、下記の記事を参考に作成してください。 AWS ユーザーガイド アクセスキー ID とシークレットアクセスキー プロファイルの設定がまだの方は、aws configure --profile プロファイル名 で設定できます。 $ aws configure # デフォルトのプロファイルを設定 $ aws configure --profile Name # 名前付きプロファイルを設定 2. ビルド デプロイ先の AWS アカウントのプロファイルの設定が完了したら、sam build コマンドでビルドします。 $ sam build Building codeuri: /path/to/project/dir/SamTest/hello-world runtime: go1.x metadata: {} functions: ['HelloWorldFunction'] Running GoModulesBuilder:Build Build Succeeded Built Artifacts : .aws-sam/build Built Template : .aws-sam/build/template.yaml Commands you can use next ========================= [*] Invoke Function: sam local invoke [*] Deploy: sam deploy --guided 以上でビルド完了です。 3. デプロイ はじめてデプロイする場合は、sam deploy --guided コマンドを利用し、スタック名やリージョンなどを指定します。 $ sam deploy --guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Not found Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: SamTest AWS Region [ap-northeast-1]: #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y # Yes を選択 #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: Y # Yes を選択 HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y Save arguments to configuration file [Y/n]: # Yes を選択 SAM configuration file [samconfig.toml]: # デフォルトの samconfig.toml で作成 SAM configuration environment [default]: # デフォルトの default で設定 ～省略～ Successfully created/updated stack - SamTest in ap-northeast-1 下記に、質問される内容を記載しておきます。 スタック名：CloudFormation にデプロイするスタックの名前。これはアカウントと地域に固有である必要があります。プロジェクト名から始めるとわかりやすいです。 AWSリージョン：アプリをデプロイする AWS リージョンを指定します。 展開前に変更を確認する：Yes に設定すると、デプロイするときにリソースの変更内容を確認できます。No に設定すると、リソースの変更内容が表示されないまま自動的にデプロイされます。 SAM CLI IAMロールの作成を許可する：AWS SAM テンプレートは、作成された Lambda ファンクションが他の AWS サービスにアクセスするために必要な IAM ロールを作成します。デフォルトでは、最低限必要な権限を持つIAMロールが作成されます。Lambda にアタッチする IAM ロールを自分で作成する場合には、オプションで --capabilities CAPABILITY_NAMED_IAM を指定する必要があります。 引数をsamconfig.tomlに保存：Yes に設定すると、選択した内容がプロジェクト内の samconfig.toml ファイルに保存されます。samconfig.toml を作成しておくと、次回以降のデプロイは sam deploy コマンドだけで実行することが可能です。 質問にひと通り回答したら、ビルドしたプログラムが S3 にアップロードされ、template.taml で定義した AWS リソースが作成されていきます。 "Successfully created/updated stack" というメッセージが表示されたら、デプロイ完了です。 ターミナルに表示されている Outputs に、デプロイされた Lambda ファンクションのエンドポイント（Value）が記載されています。 Key HelloWorldAPI Description API Gateway endpoint URL for Prod environment for First Function Value https://xxxxxxxx ブラウザからエンドポイントにアクセスしてみます。 以上のように表示されれば、デプロイ成功です。 ここから少しずつコードに変更を加えたり、SAM テンプレートに変更を加えたりしていくと、オリジナルのサーバーレスアプリケーションを開発することができます。 AWS コンソールから各サービスを確認 最後に、AWS のコンソールから作成したアプリの各サービスを見てみます。なお、各サービスには自動で名前がつけられていますが、SAM テンプレートを使って任意の名前をつけることができます。 CloudFormation CloudFormation > スタック の順に開くと、sam deploy --guided で指定したスタック名でスタックが作成されていることがわかります。スタック名をクリックすると詳細を確認できます。SAM CLI を使ってデプロイした場合、SAM テンプレートの内容をもとに CloudFormation で各リソースが作成されることがわかると思います。2 回目以降のデプロイでは、このスタックを更新して各リソースに変更を加えていくことができます。 AWS Lambda Lambda > 関数 の順に開くと、新たに Lambda ファンクションが作成されていることがわかります。関数名から詳細を確認できます。 API Gateway API Gateway を開くと、新たに API が作成されていることがわかります。API 名から詳細を確認できます。 CloudWatch ロググループ CloudWatch > ロググループ の順に開くと、新たにロググループが作成されていることがわかります。ロググループ名から Lambda のログファイルを見ることができます。 以上で当記事の内容は終了です。お疲れさまでした！ おわりに 説明が簡単になってしまったところや、今回書ききれなかった内容などは、時間を見つけて修正したり続編の記事などを書いていけたらと思っています。 下記のような内容に興味がある方がいたら、LGTM いただけるとありがたいです。今後の参考にさせていただきます。 SAM テンプレートのおすすめの設定 Makefile のおすすめの設定 SAM を使った開発でのリモートデバッグの方法 Lambda から安全に RDS や Aurora に接続する方法 SQS をトリガーにした Lambda ファンクションの開発 最後までお読みいただき、ありがとうございました！