公式ドキュメント通り、PythonでLambda Layersを作成して、既存の関数にAttachして実行したところ、以下のようなErrorが発生した。
Unable to import module 'xxx' : No module named 'xxx'
あれ。何か間違えたかな、とフォルダ構成を確認し、Lambdaの実行環境でフォルダの所在を確認してみてもちゃんとある。
print(os.listdir('/opt/python')) xxx.py
これ、ほんとになんでかわからず散々あれこれ検証してみたところ、どうも「/opt/python」にパスが通ってないっぽい。その筋で検索すると以下のような記事が出てきた。
すぐに環境変数を確認してみるとPYTHONPATH定義している。 これだ。。 これはわからなんだ。。公式ドキュメントとかにも特に言及されておらず、想像もできなかった。
↑の記事では使うなと書いていたけど、既存の関数で既に定義されていてそれはそのままにしておきたかったので、単純に「/opt/python」を追加したところ、うまく読み込めるようになった。
from datetime import datetime, timedelta, timezone ~~~ JST = timezone(timedelta(hours=+9), 'JST') now = datetime.now(JST) strf_now = (now.strftime('%Y-%m-%d_%H-%M-%S_%f')[:-3])
PythonでとあるAPIを呼び出す処理を記述し実行したところ、以下のようなエラーが返ってきた。
420 Enhance your Calm
日本語訳にかけても意味不明でなんじゃこりゃ？って感じだったが、どうやら速度制限に引っかかった場合に返されるらしい。
そこでAPI呼び出し直前にsleep処理などを入れてみたが特に変わらず、あれこれするうちにリクエストのbodyをjson化していないことが原因っぽく、以下のような記述を追加することで出なくなった。
req_body = json.dumps(req_body)
なんかもうちょっとわかりやすいエラーメッセージなかったのかなとブツブツ言いつつ、一件落着。
API Gatewayのステージでステージ変数を設定し、Lambda側でバージョンとエイリアスを設定して紐付けて呼び出すよくある構成で構築し、API Gatewayの画面に出てきたURLを叩いてみると「Internal server error」と表示される。
API Gatewayのステージ変数はちゃんと設定できていて、リソースのテストでステージ変数を入力して実行するとちゃんとレスポンスが返ってくるし、
Lambda側のリソースベースのポリシーステートメントはちゃんと設定できている。
つまらないオチになりますが、結局原因はステージに表示されているURLをクリックしてもGET送信となるだけで、POSTやPUT送信にはならないことが原因でした。レスポンスが別タブで表示されている時点で気が付くべきでしたが、リソースメニューのテストではPOSTやPUTで送信してくれるので、ステージの方でもなんかうまいことURLをクリックするだけでPOST/PUTで送ってくれるのかと思い込んでいたという初歩ミスです。
ターミナルからcurlで実行するとちゃんとレスポンスが返ってきました。
2023年２月頃、AWSから以下のようなメールが届いた。
どうやら今使用しているDockerイメージのバージョンのサポートが3月で切れるらしい。ってことで、このバージョンをあげます。
CodeBuild→ビルドプロジェクト→対象のビルド→編集ボタン→環境、で今回はイメージのバージョンを「4.0」から最新の「6.0」に変更して完了です。
ただしこれ、バージョンによって使用可能なランタイムが変わってくるので以下を確認してご注意を。 docs.aws.amazon.com
以上！
LambdaからEFS上のファイルを操作する必要があったので、その設定方法をメモ書き。
まず、前提としてEFSはVPCの内側、Lambdaは外側にあるサービスなので、そのままでは当然アクセスすることができない。
解決策としてLambdaをVPCの中、さらにEFSがマウントポイントを貼っているSubnetの中に設置してやり、アクセスポイントで繋いでやることでLambda→EFSにアクセスすることが可能になる。イメージとしてはこんな感じ。
ではひとつひとつやっていきます。
Lambdaの設定の方ですが、VPC内のEFSにアクセスするために、LambdaをVPCの中に設置してやる必要があります。
まずはVPCの設定するためLambda実行ロールの権限の設定から。Lambdaの実行ロールは以下で確認、及び設定画面へ移動できます。
VPCの設定に必要な「AWSLambdaVPCAccessExecutionRole」、またついでにEFSへのアクセスに必要な「AmazonElasticFileSystemClientReadWriteAccess」、及びCloudWatchへのアクセス権「CloudWatchLogsFullAccess」も一緒に付与しておきます。
(ポリシー名)
そしてLambdaをVPCの中に設置する設定箇所がここの部分↓（※Lambda作成の手順に関してはここでは省略します）
ここでEFSが現状マウントされているEC2やFargateなどが存在するVPCとSubnetを指定してやります。今回はLambdaからEFSへアクセスするだけなので、セキュリティグループはインバウンド、アウトバウンド共に何もなしの内容で問題ない。
EFSがマウントされているSubnetは、EFS側の画面でも確認できます。
これで今↓のような感じで、LambdaがEFS（のマウントポイント）と同じ場所に配置された状態になります。
後はLambdaとEFSを繋いでいく作業になります。今回EFSは既にEC2などと繋いで利用している想定で、EFSをゼロから作成する部分の作業手順は他の記事に譲るものとします。
LambdaからEFSにアクセスするには、EFS側に「アクセスポイント」というインターフェイスが必要になります。EFSのマネジメントコンソールの画面では以下になります。こちらを作成してゆく。
入力する値は他の同様の記事にもある通り以下で指定します。ここの「パス」で指定したパスが、LambdaからEFSを操作する時の、EFS側のデフォルトパスとなります。
これでEFS側にLambdaからのアクセスを受けるアクセスポイントの作成まで完了しました。
今度はLambdaの方で、↑で作成したアクセスポイントを指定してファイルシステムのマウント設定を行います。「ファイルシステムID」で対象のEFSを選択、アクセスポイントIDに↑で作成したアクセスポイントのアクセスポイントIDを指定します（EFS側のアクセスポイント設定画面で確認可能）。「ローカルマウントパス」はLambda側のマウントパスになります。例えばここに「/mnt」と指定した場合、Lambdaの「/mnt」とEFSの「/data」ディレクトリがマウントされることとなり、例えばLambdaで「ls /mnt」を実行すると、EFS側の「/data」配下のファイルの一覧が表示される、という形になります。
ここまでくれば後は権限回りの設定のみで、以下の部分を設定していきます。
EFSのセキュリティグループにLambdaからのアクセスを許可するよう、LambdaのセキュリティグループのIDを指定します。EFSのセキュリティグループはコンソール画面の以下で確認可能。
LambdaのセキュリティグループIDは以下で確認可能でした。
これで以下の状態が完成したかと思います。お疲れ様でした！
2023/2/17、AWSのSOA（SysOps Administrator：SOA-C02）を受けて合格したので情報共有したいと思います。
何年か前にSAAは取得しており、同じアソシエイトクラスの資格なので同じくらいの難易度を想定していたのですが、全く違いました。
というのもこれ、プロフェッショナルクラスにした方がいいんじゃないの？っていうくらい難しかったです。出題範囲もめちゃくちゃ広いし、唯一ラボの試験がある資格ということで、サービスの概要をわかっていればいいという内容ではなく、各サービスの細かい設定項目やそのユースケース、さらに基礎的なサービスに関してはコンソールで実際に設定できる知識が必要になります。受験の際には「ナメてかからない」ことを強くお勧めします（私は最初そうして1度落ちました）。
SAAの時はUdemyの問題集のみで合格できたため、今回も最初はUdemyの「【SOA-C02版】AWS 認定SysOpsアドミニストレーター アソシエイト模擬試験問題集（全4回分294問）」だけを２周実践し受験しましたが、見事に落ちました。
その後他の関連ブログ記事のアドバイスを受け、TechStockのAWS WEB問題集サービスに課金し、そこで２ヶ月かけて700問近くの問題を解いてようやく合格したという経緯です。勉強方法としてとにかく問題を解いてわからないことをノートにまとめて書き出し、風呂に入っている時にそのノートを読み返す、ということを繰り返しました。またよく出題されるサービス（VPC, Subnet, AutoScaling, ALB, EC2, S3, etc）などに関しては可能な限り手を動かして構築ということもやりました。BlackBeltを全部目を通しておく、ということをアドバイスされている記事も多くありましたが、私の場合は一度も見ずにひたすら問題集だけこなした形でした。
あくまでも私個人のやり方ですが、筆記対策に関しては、まとめて書き出すことで自分なりに整理して腑に落とす形で頭にも記録にも残せる、また風呂の時間にそれを読み返すようにすることで反復復習を日常の中に組み込むことができるのでお勧めです。
一点だけ声を大にして言いたいことがあります。タイトルにもある通り、これを伝えたいがために今回この記事を書いた側面もあるのですが、それは、「AWS SOA は絶対に自宅でテストしてはいけない」ということです。
今回、私は試したことがなかったので初めて自宅でテストを受講したのですが、これでえらい目に遭いました。受験開始直後からマウスの反応がワンテンポ遅れるなというのは感じていたのですが、筆記テストの段階では４択の選択肢から一つポチっと選んで「次へ」ボタンを押す程度だったので支障というほどの影響はありませんでした。ところがラボの問題になるとコレが甚大な影響を及ぼし、というのも一つ一つの操作に10秒ほど要する、画面をスクロール=10秒、リソースの名前に「test」と入力するのにも、「t」で10秒、「e」で10秒、「s」で10秒、「t」で10秒、という具合で、とてもじゃないけどテストどころではない状況でした。監視員役の方にチャットで連絡するも外国の方なので自動翻訳の変な日本語で会話にならず、結局2問あるラボ問題の1問目も終えられずテストが終了してしまいました。回答はわかっているのに入力が遅すぎて、または何度もフリーズして、回答できない状況にやるせない気持ちになり、心底疲れました。。
今回、おそらくたまたま筆記の方で点を稼げていたためラボの分をカバーしてギリギリ合格となりましたが、ラボの割合は20%あるので影響は大きく、全ての人に起こるワケではもちろんないとは思いますが、私のような事象が発生するかもしれない可能性を考慮すると、ラボ問題があるSOAの試験は自宅ではなくテストセンターで受験する方が無難かと思われます。
ちなみに今回の私のPC環境ですが、2021年M1チップ搭載のMacBookProで、ネット接続はWifiでしたら事前のOnVue（自宅テストのアプリ）パフォーマンステストでも問題なく、ネットはサクサク動くような環境でした。Macとの相性が悪いとの記事もあったためWindowsだと起こらないのかもしれませんが、いずれにせよこのテストでの自宅受験の選択はリスクが大き過ぎると思いますので、避けた方が良いと思います。
前回は午後に受験して翌朝の5時に通知結果がメールで届いたのですが、今回は2日後の朝に通知が来ました。ラボのことがあったので気になり、翌日にAWS Training & Certificationのページに見にいったらすでに結果が出ていました。遅いなという時はこういうケースもあるかもしれないので、直接AWS Training & Certificationのページに見にいってみると良いかと思います。
以上、どなたかの参考になれば幸いです。