本記事では、以下の前提で解説します。<ul><li>プライベートサブネット内にEC2インスタンスが配置されている</li><li>AWS Identity and Access Management (IAM) の適切な設定がされている</li></ul>

前提

EC2 Instance Connectを使用すれば、踏み台サーバーや有料のVPCエンドポイントを作成する必要がありません。よってコストを削減することができます（個人的にこれが一番嬉しい） プライベートサブネットにあるEC2にEICを利用するには、EC2 Instance Connect Endpoint を作成する必要がありますが、インターフェース型のVPCエンドポイントとは異なり、料金は発生しません。

1. コストを抑えられる

従来のSSH接続では、秘密鍵の管理が必要ですが、EICでは一時的なSSHキーを使用するため、鍵の管理や漏洩リスクを減らすことができます。

2. SSH鍵の管理が不要

IAMポリシーを利用して、どのユーザーがどのEC2にアクセスできるかを制御できます。これにより、必要な権限を持つユーザーだけがEC2に接続できるようになります。

3. 簡単なIAM権限管理

踏み台サーバーによるSSH接続、SSM Session Manager、EC2 Instance Connectの比較をするとこんな感じです。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/40af26630c574f1d8b2f46376efbffe4/image.png" alt="">

比較表

EC2 Instance Connectを利用するメリット

先に言っておくと、使いづらいところもあります。<ul><li>一つのVPCに対して1つのEICエンドポイントしか設定できない<ul><li>複数サブネットにEC2がある場合は不便です。。</li></ul></li><li>DBeaverなどのデータベース管理ツールでSSHトンネルでのDBインスタンスへの接続はできない<ul><li>上記を実現するには踏み台サーバー一択かも？</li></ul></li></ul>

EC2 Instance Connectの痒いところ

プライベートサブネットにあるEC2にEICを利用するには、EC2 Instance Connect Endpoint （以下、EICエンドポイント） を作成する必要があります。ただその前に、EICエンドポイントにアタッチするセキュリティグループを作成します。<ul><li>インバウンドルール<ul><li>特に設定する必要なし。</li></ul></li><li>アウトバウンドルール<ul><li>EC2インスタンスのセキュリティグループを許可します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/d669783403354aae839c61f44ec51a4c/image.png" alt=""></li></ul></li></ul>上記ルールを設定すればOK。

1. EC2 Instance Connect エンドポイント用のセキュリティグループを作成

次に、先ほど作成したセキュリティグループを使ってEICエンドポイントを作成します。<ul><li>VPCマネジメントコンソールで「エンドポイント」を選択し、「エンドポイントを作成」をクリック</li><li>タイプ：「EC2 インスタンス接続エンドポイント」を選択<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a9770ac435804063afbff87a4ae21783/image.png" alt=""></li><li>ネットワーク設定<ul><li>EC2インスタンスが配置されているVPCを選択します。</li></ul></li><li>セキュリティグループ<ul><li>1で作成したセキュリティグループをアタッチします。</li></ul></li><li>サブネット<ul><li>EC2インスタンスが配置されているサブネットを選択します。</li></ul></li><li>※見落としがち！クライアントIPの保持<ul><li>SSH接続先のEC2にIP制限を設けたい場合は「クライアントIPの保持」にチェックを入れてください！有効化するとEICエンドポイントは、クライアントIPのアドレスを保持する様になるため、インバウンドルールにて、特定のクライアントIPを許可する設定が可能になります。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fc3ce98b8c984a5e99710d62f1ccba67/image.png" alt=""></li></ul></li></ul>上記設定で「エンドポイントを作成」を押せばEICエンドポイントの作成が完了します。

2. EICエンドポイントを作成

EC2側のセキュリティグループ（インバウンドルール）を設定します。特定のIPアドレスのみSSH（ポート22）を許可するように設定します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/881712727d084c2191a3b814429a8651/image.png" alt="">

3. セキュリティグループの設定

設定手順

<ul><li>該当のインスタンスを選択</li><li>「接続」をクリック</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c9c0ef7255904e958898ba1fc1eca7a7/image.png" alt=""></li><li>EC2 Instance Connectのタブから「EC2 Instance Connect エンドポイントを使用して接続する」を選択して接続。</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/13ea4512818f47b091fa26ce08b67c4a/image.png" alt=""></li><li>じゃーん</li><li><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e71ebaa55786477b985f668037713cc4/image.png" alt=""></li></ul>

マネコンから

インスタンスIDがわかっていればローカル端末から接続することも可能です。<pre><code>$ aws ec2-instance-connect ssh --instance-id i-0e5e0f3e85568e95e --connection-type eice</code></pre> じゃーん<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/216afa2a8d4e46608aaaf3f4c715f1ed/image.png" alt="">

ローカルからCLIで接続

接続してみた

AWSの運用コストに関してシビアなプロジェクトであれば、少しでも運用コストは下げたいところ。今回のEC2 Instance Connectが一つの選択肢になれば幸いです。

終わりに

EC2 Instance Connectでコスト削減！プライベートサブネットのEC2に接続してみたよ

Githubのmainブランチが更新されたら自動デプロイできるようにする具体的には下記の手順を自動で行えるようにします。<ol><li>Githubのmainブランチを変更</li><li>GithubActionsが作動し、S3にファイルをアップロード</li><li>Lambda関数が発火し、CloudFrontのキャッシュを削除する</li></ol> 図にするとこんな感じです<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4ed975a03ea9499b80ce3901f3f296a0/image.png" alt="">

今回やりたいこと

まずは事前準備として、GithubActionsからCLIでS3のバケットにアクセスするための権限を持っているIAMユーザーを作成します。 1.ユーザー名は分かりやすく「GithubActions」に設定します。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/41297af906ad4982b5bf3bc0106e7fbf/image.png" alt="">2.S3へのアクセスを付与します。　「ポリシーを直接アタッチする」を選択し、<a style="color:inherit" href="https://us-east-1.console.aws.amazon.com/iam/home?region=ap-northeast-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAmazonS3FullAccess" target="_blank" rel="noopener noreferrer">AmazonS3FullAccess</a>を追加<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ae26824587ee44f3baab32c4af9855c0/image.png" alt="">3.S3にアクセスするためのキーを取得します。　IAMユーザー作成後、「セキュリティ認証情報」&gt;「アクセスキーを作成」　ユースケースの選択画面では「AWS の外部で実行されるアプリケーション」を選択　　→アクセスキー、シークレットアクセスキーが発行されるのでどっかにコピーしておく 4.Githubのリポジトリにアクセスキーとシークレットアクセスキーを環境変数として設定　Githubのリポジトリの「Settings」タブのRepository secretsから登録できます。　<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/c17fc1aad29e49078742db771c34c053/image.png" alt=""> これにて事前準備は完了です。

GithubActionsからS3へアクセス可能にしよう

次にGithub 側の設定です。mainブランチに変更があった際にS3へファイルをアップロードする処理を書いていきます。 導入の仕方は以下の公式ドキュメントを参照してください<a href="https://docs.github.com/ja/actions/quickstart" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/quickstart</a> <code>.github/workflows</code>&nbsp;ディレクトリ配下に<code>ci.yml</code>を作成します。<pre><code>name: Build and Deploy to S3


on:
 # mainブランチへのプッシュをトリガーにする
 push:
 branches:
 - main


jobs:
 build-and-deploy:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@main # リポジトリをチェックアウト 


 - name: Install Dependencies
 run: npm install
 # ビルドしてdistディレクトリ以下のファイルを更新
 - name: Build
 run: npm run build 


 - name: Deploy # S3にデプロイ 
 env:
 # IAMユーザーに作成したアクセスキー
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 run: | # S3のバケットにデプロイ
 aws s3 sync --region ap-northeast-1 ./dist s3://nuxt-app-20240218 --delete
 aws s3 cp --recursive --region ap-northeast-1 ./dist s3://nuxt-app-20240218</code></pre> <code>git push origin main</code>コマンドを実行。無事、処理が完了したみたいです。S3にもアップロードされていることを確認できました。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/fb8c75b3b0ef4f6188ff72a3e70b4449/image.png" alt="">

ワークフローの作成

①GithubActionsを使った自動デプロイ

Python3.9を使って、関数を1から作成していきます。関数名は「delete-cache-cloudfront」としておきます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/483aacf31399478bbf243fd36e7dd4dc/image.png" alt="">

Lambda関数の作成

Lambda関数からCloudFrontにアクセス権限を付与する必要があります。以下の手順で設定<ul><li>作成したLambda関数の設定タブの「アクセス権限」から、実行ロールのリンクをクリック</li><li>IAMロールの画面に飛ばされるので「許可の追加」から「ポリシーのアタッチ」をクリック</li><li>CloudFrontで検索すると<a href="https://us-east-1.console.aws.amazon.com/iam/home#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FCloudFrontFullAccess" target="_blank" rel="noopener noreferrer">CloudFrontFullAccess</a>が出てくるので選択して許可を追加</li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/31079a3315a541cfb3ee0f30a8fbd4cf/image.png" alt="">

アクセス権限の付与

関数の概要の「トリガーを追加」をクリック。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/60f918dfe8b54bfc89b4a825ea6d0a74/image.png" alt="">以下の内容で設定し、追加を押下<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5fc8cf095a8d49fabc0b5ff1062ad358/image.png" alt="">

トリガーの作成

Lambdaを使ったキャッシュクリア

まずは変更前の状態を確認。CloudFrontのディストリビューションのドメインにアクセス<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/94d565f35cae494c947b8821b5721e85/image.png" alt="">CloudFrontのキャッシュ削除履歴最終履歴は2024年3月5日 15:03:11<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/86a73a40087b42c9a2431affcdc9a9e8/image.png" alt="">今回はタイトルバーの「MyApp」の文字列を「YOKU」に書き換えます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b490c4d0335544b0a7b3358f3f96ccd2/image.png" alt=""> 変更をコミットして<code>git push origin main</code>を実行！ キャッシュ削除することなく、きちんと変更が反映されていました(^ ^)<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e484fe389dcb454ea7db9ffb168bb6bb/image.png" alt=""> ちなみにCloudFrontのコンソール画面のキャッシュ削除履歴も2024年3月5日 15:13:07に更新されています。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/a513f0e6d4384d809ca378d45f96102c/image.png" alt="">

動作確認！

実務でアプリを運用していくことを想定して、デプロイを仕組み化することでヒューマンエラーを防いでいきたいと思いました。

最後に

mainブランチにマージ→S3にデプロイ→CloudFrontのキャッシュ削除まで自動化してみた

<ul><li>この記事に書くこと<ul><li>S3にNuxt.jsのファイルをデプロイする方法</li><li>CloudFrontのディストリビューション作成、設定方法</li></ul></li><li>この記事に書かないこと<ul><li>S3, CloudFrontについての概要、基礎知識</li></ul></li></ul>

バケット名　→今回は<code>nuxt-app-20240218</code>というバケット名で作成。オブジェクト所有者　→「ACL有効」に設定　※ACLを無効にすると、バケットのオブジェクトの公開設定ができなくなる。　　今回は静的Webホスティングとして公開するため、有効に設定デフォルトの暗号化　→無効に設定。　作成完了。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/450a1c9ed1834015ad239dd259c44395/image.png" alt=""> 作成したバケットを静的webホスティング用に設定していく。上記のバケット詳細の画面の下の方に「静的webホスティング」のセクションがあるのでそこから編集。　→静的webホスティングを有効に設定

S3バケットを新規作成～静的webホスティング設定

distディレクトリとはNuxtのプロジェクトをビルドした際に生成されるファイル群。.vue形式で記述したファイルが、htmlで作られた Web サイト用のファイルに変換されます。※distディレクトリごとアップロードしてしまうと、Webページにアクセスした際にindex.htmlがなく403となってしまうので注意！ 無事アップデート完了。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/08bc12b91b11486ea8e4a6b08cb11690/image.png?w=500&amp;h=401" alt="">

S3にNuxtのファイル(distディレクトリ配下)をアップロード

次に、https通信を実現するためにSSL証明書を発行していきます。主な手順としては以下の通りです。<ol><li>ドメインを購入（今回はお名前ドットコムを利用）</li><li>Route53でホストゾーンの設定</li><li>ACMを使ってパブリック証明書をリクエスト<ol><li>注意：CloudFrontで利用するためにはリージョンをバージニア北部に設定してリクエストを行う必要がある</li></ol></li><li>Route53でDNSレコードを作成（CNAMEタイプ）</li></ol> 詳細な手順は以下の記事を参考にしましたので参照ください。<a href="https://dev.classmethod.jp/articles/route53-domain-onamae/" target="_blank" rel="noopener noreferrer">https://dev.classmethod.jp/articles/route53-domain-onamae/</a>

SSL証明書を発行

事前準備

Origin domain　→作成したS3バケット名を入力<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/f9d071a6d5e144d8bed17d90abeb78ec/image.png" alt=""> オリジンへのアクセス制限<ul><li>　OAIを作成<ul><li>OAIとは？</li><li>→CloudFront内に存在する仮想的なユーザーみたいなもの。このユーザーの権限を使ってS3へのアクセス制限を行うことができる。</li><li>今回はこのOAI（CloudFront）経由でのみS3にアクセスできるようにする。</li></ul></li><li>バケットポリシーを設計する必要があるので「はい、バケットポリシーを自動で更新します」を選択 <ul><li>CloudFront側で設定したポリシーがS3側でも自動で適用される</li></ul></li></ul>　　　<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/9fede0a4dced46e7809fcd55f063e6d1/image.png" alt=""> オリジンシールドの適用　→オリジンの負荷を最小限に抑え、可用性を向上させてくれる<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/ee9157e4ae4742e5bf27555bcbea9fe9/image.png" alt=""> ビューワーの設定<ul><li>Redirect HTTP to HTTPS<ul><li>httpでアクセスした際に自動でhttpsにリダイレクトしてくれる</li></ul></li><li>今回はWebサイトの閲覧が目的なのでGET, HEADメソッドのみ</li><li>今回はWebサイトの公開が目的なのでNoに設定 （yesにするとキーペアを作成する）</li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5750c900110a48b1a3b9d1691cc3508d/image.png" alt="">https通信を実現させるための設定<ul><li>代替ドメイン名に取得したドメイン名を入力</li><li>SSL証明書はACMで発行した証明書を選択</li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/3e37326d675244b5ac614b7c6e180f47/image.png" alt=""> ディストリビューション作成完了！<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4f0e0bf736524bb6895b15225969fa16/image.png" alt="">

作成時の設定

CloudFront ディストリビューションを新規で作成

<ol><li>Route53で作成したホストゾーンから、「レコードを作成」を選択</li><li>エイリアスを有効にして、「トラフィックのルーティング先」をCloudFrontに設定すると自動でディストリビューションが表示される</li></ol><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/7e2e41d044b64baea572f4cdfa26d080/image.png" alt="">

ドメインとの関連付け

S3＞バケット＞バケット名＞バケットポリシーを編集<ul><li>①があらかじめS3に設定したバケットポリシー。（誰でもアクセスできる状態）</li><li>②がディストリビューション作成時に作成したバケットポリシー （OAIを新規作成して、そのCloudFrontからでしかアクセスできない）<ul><li>①のバケットポリシーを削除</li></ul></li></ul><img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/73ae18372d9e463a9b413d58e5e14bfc/image.png" alt=""> この設定により、変更前はS3のオブジェクトURIへ直接アクセスしてページを閲覧できていましたが、変更後はForbiddenで閲覧できなくなりました

S3でOAIがうまく機能しているかを確認

レコード名を貼り付けてアクセス<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/67061f93b9a246e09a69a9e0b2adfd4c/image.png" alt="">無事、アクセスすることができました。（今はドメインの更新をしていないのでディストリビューション名のドメインからアクセスしてます。）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4c109960d1af4826b6a6f7ef052c1343/image.png" alt="">

CloudFrontからアクセス！

CloudFrontを経由してアクセスしてみよう

今回S3にフロントエンドのプロジェクトをデプロイしてCloudFrontで配信する構成をしてみました。 思ったのは、リリースのたびにS3にアップロードして、キャッシュを削除しないといけないので少し面倒だということです。 次回はデプロイの一連のワークフローのパイプラインを作っていきたいと思います。

おわりに

Nuxt.jsをS3にデプロイしてCloudFront経由でアクセスする

以下の例を参考に<code>ssh-keygen</code>を実行して鍵を生成します。<pre><code>$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ec2-user/.ssh/id_rsa): そのままEnter
/home/ec2-user/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): そのままEnter
Enter same passphrase again: そのままEnter
Your identification has been saved in /home/ec2-user/.ssh/id_rsa.
Your public key has been saved in /home/ec2-user/.ssh/id_rsa.pub.
The key fingerprint is:
ce:97:a8:d8:3b:d4:8d:95:22:68:e0:e2:8e:58:8d:ce ec2-user@ip-x-x-x-xx
The key's randomart image is:
+--[ RSA 2048]----+
| . 省略&nbsp;&nbsp;.&nbsp;&nbsp;&nbsp;|
+-----------------+

$ cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAyZfh5ztQIQCwPIQAGFZD9kv1ihU9RP9WCBsfSp7JlNs0eNol
...省略
-----END RSA PRIVATE KEY-----

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDJl+HnO1AhALA8hAAYVkP2S/WKFT1E...省略</code></pre>

1. ssh-keygenで公開鍵、秘密鍵を作る

以下の手順で公開鍵をCodeCommitのIAMユーザーに登録します。 <ol><li>AWSコンソールにログイン</li><li>IAM &gt; セキュリティ認証情報 &gt; AWS CodeCommit認証情報 を開く</li><li>AWS CodeCommitのSSH公開キー の 「SSH公開キーのアップロード」を押下</li><li>先ほど生成したid_rsa.pubの中身をコピペしてアップロードする。※アップロードするのは<code>id_rsa.pub</code>なので注意すること。<code>id_rsa</code>は絶対にアップロードしない。</li><li>アップロード完了してSSH Key ID が生成されたらOK</li></ol>

2. 公開鍵をCodeCommitのIAMユーザに登録する

~/.ssh/configに以下の設定を追記します。(configが無い場合は作成してください) <pre><code># プロジェクト名
Host git-codecommit.ap-northeast-1.amazonaws.com
&nbsp;&nbsp;User &lt;先ほど生成した SSH Key ID&gt;
&nbsp;&nbsp;IdentityFile ~/.ssh/id_rsa</code></pre>

3. .ssh/configに設定を追加する

CodeCommitからSSHのクローンでgit cloneします。成功したら設定は完了です。

4. ssh接続でgit cloneする

AWS CodeCommitからSSH接続でgit cloneする

アイテムをテーブルに1件追加したい場合にはput_item()を使用します。<pre><code>table.put_item(
 Item={
 'username': 'janedoe',
 'first_name': 'Jane',
 'last_name': 'Doe',
 'age': 25,
 'account_type': 'standard_user',
 }
)</code></pre>

DynamoDB.Table.put_item():

アイテムの追加

一度に大量のデータをロードする場合は、batch_writer()を利用すると、プロセスを高速化し、サービスに対する書き込みリクエストの数を減らすことができます。DynamoDBは一度にputできる数が最大25という制限がありますが、boto3のbatch_writer()を使えば、特に気にすることなくよしなにやってくれます。 <pre><code>with table.batch_writer() as batch:
&nbsp;&nbsp;batch.put_item(
&nbsp;&nbsp;&nbsp;&nbsp;Item={
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'account_type': 'standard_user',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'username': 'johndoe',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'first_name': 'John',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'last_name': 'Doe',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'age': 25,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'address': {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'road': '1 Jefferson Street',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'city': 'Los Angeles',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'state': 'CA',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'zipcode': 90001
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;)
&nbsp;&nbsp;batch.put_item(
&nbsp;&nbsp;&nbsp;&nbsp;Item={
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'account_type': 'super_user',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'username': 'janedoering',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'first_name': 'Jane',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'last_name': 'Doering',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'age': 40,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'address': {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'road': '2 Washington Avenue',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'city': 'Seattle',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'state': 'WA',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'zipcode': 98109
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;)
&nbsp;&nbsp;batch.put_item(
&nbsp;&nbsp;&nbsp;&nbsp;Item={
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'account_type': 'standard_user',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'username': 'bobsmith',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'first_name': 'Bob',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'last_name':&nbsp;'Smith',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'age': 18,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'address': {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'road': '3 Madison Lane',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'city': 'Louisville',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'state': 'KY',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'zipcode': 40213
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;)
&nbsp;&nbsp;batch.put_item(
&nbsp;&nbsp;&nbsp;&nbsp;Item={
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'account_type': 'super_user',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'username': 'alicedoe',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'first_name': 'Alice',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'last_name': 'Doe',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'age': 27,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'address': {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'road': '1 Jefferson Street',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'city': 'Los Angeles',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'state': 'CA',
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;'zipcode': 90001
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;)</code></pre>

DynamoDB.Table.batch_writer():

複数アイテムの追加

アイテムを1件取得するにはget_item()を使用します。<pre><code>response = table.get_item(
&nbsp;&nbsp;Key={
&nbsp;&nbsp;&nbsp;&nbsp;'username': 'janedoe',
&nbsp;&nbsp;&nbsp;&nbsp;'last_name': 'Doe'
&nbsp;&nbsp;}
)
item = response['Item']
print(item)</code></pre>

DynamoDB.Table.get_item():

アイテムの取得

ハッシュキー、ソートキー、GSIで検索する場合にはKeyを使用します。<pre><code>response = table.query(
 KeyConditionExpression=Key('username').eq('johndoe')
)
items = response['Items']
print(items)</code></pre>

DynamoDB.Table.query():

ハッシュキー、ソートキー、GSI以外で検索する場合にはAttrを使用します。MySQLなどのIN句に相当する is_in はscan()でのみ使用可能です。<pre><code>response = table.scan(
 FilterExpression=Attr('age').lt(27)
)
items = response['Items']
print(items)</code></pre>

DynamoDB.Table.scan():

複数アイテムの取得

【AWS】boto3でDynamoDBを操作するときによく使うメソッド

注意点として、table/batch_writer()メソッドは一度に25件までしか削除できないため、forループで処理する。 <pre><code>import boto3


# 削除対象のレコードのパーティションキーをリストで指定
keys_to_delete = ['key1', 'key2', 'key3']


# DynamoDBテーブルに接続
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('table_name')


# BatchWriteItemリクエストを作成するためのリスト
delete_requests = []


# 削除対象のパーティションキーを含むDeleteRequestを作成し、リストに追加
for key in keys_to_delete:
&nbsp; &nbsp; delete_requests.append({
&nbsp; &nbsp; &nbsp; &nbsp; 'DeleteRequest': {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'Key': {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 'partition_key_name': key
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; })


# BatchWriteItemリクエストを実行する
with table.batch_writer() as batch:
&nbsp; &nbsp; for request in delete_requests:
&nbsp; &nbsp; &nbsp; &nbsp; batch.delete_item(request['DeleteRequest']['Key'])


</code></pre>

コード全体

Boto3でDynamoDBのテーブルから複数レコードを一括で削除する

時間がない人のために先に結論だけ申し上げると、結局ドキュメントに記載のとおりだった。ただ、もう少し付け加えると、無限に多くのリクエストを受けられるわけではなく、RDS Proxyが利用できる最大接続数が多いほど、多くのリクエストを捌くことができた。リクエスト数が一定以上多くなるとレイテンシーが増加し、それ以上は増えないという結果になった。また後述するが使用する言語・ライブラリ・実装によっても挙動が異なる場合があるため注意が必要で、上記の結論はPython / sqlalchemy(NullPool)+pymysqlを使用した場合。

スケールするので基本的に上限はない

まずは結論から

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/72d7171be8f24408b1f68efad6c60aca/image.png" alt=""><ul><li>上記のインフラ構成で、APIをマルチスレッドで5分間リクエストを投げ続けることで検証を行った</li><li>リクエストを投げ続ける処理については<a href="https://github.com/wg/wrk" target="_blank" rel="noopener noreferrer">wrk</a>というツールを使った<ul><li>Docker化したのでローカルを汚さずにサクッと環境構築したい人は<a href="https://github.com/jtamu/http_benchmark" target="_blank" rel="noopener noreferrer">こちら</a>どうぞ</li></ul></li><li>Lambda関数の内容としては、DB接続を取得し、簡単なクエリを発行してから接続を閉じる、というもの<ul><li>言語はPython、DB接続部分のライブラリはsqlalchemyを用いた<ul><li>Lambda環境は基本的に実行が終わったら破棄されるためLambda環境内にコネクションをプーリングするメリットはあまりないため、poolclassにはNullPoolを使用した</li></ul></li></ul></li><li>Lambda関数のソースコード：</li></ul><pre><code>import os
import pymysql
import mysql.connector
import time
from sqlalchemy import create_engine, text
from sqlalchemy.orm import scoped_session, sessionmaker
from sqlalchemy.pool import NullPool

host = os.environ['RDS_HOST_NAME']
user = os.environ['USER']
password = os.environ['PASS']
db = os.environ['DB']
connect_count = os.environ['CONNECT_COUNT']
connect_timeout = os.environ['CONNECT_TIMEOUT']


def lambda_handler(event, context):
&nbsp; &nbsp; _connect()
&nbsp; &nbsp; return {
&nbsp; &nbsp; &nbsp; &nbsp; 'isBase64Encoded': False,
&nbsp; &nbsp; &nbsp; &nbsp; 'statusCode': 200,
&nbsp; &nbsp; &nbsp; &nbsp; 'headers': {},
&nbsp; &nbsp; &nbsp; &nbsp; 'body': '{"message": "Hello from AWS Lambda"}'
&nbsp; &nbsp; }


def _connect():
&nbsp; &nbsp; engine = create_engine(
&nbsp; &nbsp; &nbsp; &nbsp; 'mysql+pymysql://{user}:{password}@{host}/{dbname}'.format(user=user, password=password, host=host, dbname=db),
&nbsp; &nbsp; &nbsp; &nbsp; echo=True,
&nbsp; &nbsp; &nbsp; &nbsp; poolclass=NullPool,
&nbsp; &nbsp; )

&nbsp; &nbsp; session = scoped_session(
&nbsp; &nbsp; &nbsp; &nbsp; sessionmaker(
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; autocommit=False,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; autoflush=True,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; expire_on_commit=False,
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bind=engine
&nbsp; &nbsp; &nbsp; &nbsp; )
&nbsp; &nbsp; )

&nbsp; &nbsp; res = session.execute(text('select now()'))
&nbsp; &nbsp; for v in res:
&nbsp; &nbsp; &nbsp; &nbsp; print(v)

&nbsp; &nbsp; session.close()</code></pre><ul><li>処理件数の上限は何に依存して決まるのかを確認するため、RDSのスペックを下げた場合と、最大接続数を下げた場合についても比較検証を行った</li></ul>

検証方法

<ul><li>RDSのインスタンスタイプ: db.t3.medium（プロキシで利用できる最大接続数: 100%, 305）<ul><li>1分間に最大8万リクエスト程度が限界だった<ul><li>なお、上記はRDS(Proxy)と同じVPC上のEC2環境で実行した場合</li><li>ローカル環境で実行した場合はその半数の4万リクエスト程度が限界だった</li></ul></li></ul></li><li>RDSのインスタンスタイプ: db.t3.micro（プロキシで利用できる最大接続数: 100%, 61）<ul><li>1分間に最大6万5千リクエスト程度</li></ul></li><li>RDSのインスタンスタイプ: db.t3.medium（プロキシで利用できる最大接続数: 20%, 61）<ul><li>1分間に最大6万7千リクエスト程度</li></ul></li></ul> EC2から実行した場合のほうがリクエスト数が多くなったのは、レイテンシーが小さかったためで、おそらく、同じVPCにあるので通信のパケットが長い距離を移動しなくて済むためと考えられる。なお、2つのマシンから同時に実行した場合もリクエスト数はほぼ変わらなかったため、クライアントマシンのスペックはあまり関係なく、送れるリクエスト数の上限はネットワーク帯域的な限界で決まるのではと思った。また、RDSのスペックもあると思うが、RDS Proxyの最大接続数によって最大リクエスト数がほぼ決まることがわかった。

検証結果

<ul><li>sqlalchemyのpoolclassにNullPoolを使用せず通常のQueuePoolを使用した場合、パフォーマンスが大幅に悪化した。<ul><li>Lambda環境は破棄されるがコネクションは紐付いた状態のままになるため、RDS Proxy側で再利用できないのが原因と考えられる</li></ul></li></ul>

その他わかったこと

具体的な検証内容

sqlalchemy(NullPool)+pymysqlを使用した場合は<code>session.close()</code>してもコネクション自体は切れずにプロキシでプールされ別の接続リクエストに再利用されるが、 pymysqlを単体で使用した場合はコネクションがプールされずに毎回切れる、という全く異なる挙動を示した。これによりpymysqlを単体で使用した場合はパフォーマンスが悪化し、リクエスト数が多くなるとレイテンシーの増加だけでなく接続失敗も発生するようになった。問題はコネクションの部分なのでクエリのログには原因を示すようなログは特に見当たらず、解決のためにはTCP接続の部分やソースコードなどを掘り下げていく必要があり時間がかかりそうだったため、今回はそこまで深追いすることはやめた。

使用するライブラリによって挙動が全く異なる

残る謎

Lambdaの課金は実行回数によって決まるため、最初なるべく実行回数を少なくしようとして1関数の中でループして500個のDB接続を取得するようにしていた。この関数を単体で実行したときは正常に動作したが、DBリクエスト数が2万件くらいになったあたりからレスポンスが正常に返ってこなくなった。Lambdaのエラーログには<code>Lost Connection</code>となっていたのでRDSの設定などを見直していたが、 最終的にAPI Gatewayの時間制限(30秒)に引っかかっていることがわかった。知っていれば回避できたと思うが、この問題の解決にかなりの時間を費やしてしまった。RDSのサービスを使う際には予め制約を把握しておくことが重要ということが身にしみてわかった。

API Gatewayの時間制約に翻弄される

苦労した点

RDS Proxyの負荷検証を行った件について

(...なんかみんな当たり前にNginxの設定してるけど何考えてるの？？.....僕もとりあえずやってみよ.....あ、なんか動いたからこれでいっか.....)↑これやっちゃってる人いるでしょ！！！ダメですよ！！！ということでnginxの設定値を導き出したので今回触っていきましょう。

Nginxの設定って何を基準にすればええねん！！！

経緯

<blockquote>Nginx(エンジンエックス)は、高性能かつ軽量なWebサーバーであり、リバースプロキシや負荷分散の機能を持つプロキシサーバーとしても使用されます。また、Nginxは、静的コンテンツの配信、FastCGI、WebSocket、SSL/TLSなどの機能をサポートしています。 Nginxは、シングルプロセス・イベント駆動型アーキテクチャを採用しており、高い同時接続数を処理することができます。また、モジュール機構を持ち、ユーザーが自由に拡張することができます。 Nginxは、オープンソースソフトウェアであり、高いパフォーマンスと安定性、セキュリティに優れているため、世界中で多くのWebサイトやアプリケーションで使用されています。</blockquote> ほうほう。つまり簡単にいうと高性能なwebサーバーっちゅうことか。別の有名どこでいうと"Apache"っちゅうもんがあるな。(今回はNginxメインだから今度触れることにしよう。）

そもそもNginxってなんぞや？

前にwebアプリケーションの構築してるときに下記の設定パラメータがあったんだよね。<pre><code>worker_rlimit_nofile
worker_processes
worker_connections</code></pre> .....なんだよこれ！！！！！適正値なににすればいいの？！！ ということで一緒に適正値を設定していきましょう。の前に上記設定パラメータの説明載せときますねい。<blockquote>Nginx Webサーバーのパフォーマンスとリソース使用量を制御するための重要な設定</blockquote><ul><li><code>worker_rlimit_nofile</code>は、各Nginxプロセスが開くことができるファイルディスクリプタの最大数を制限するための設定です。ファイルディスクリプタは、オープンされたファイル、ソケット、パイプなどのリソースへの参照を表します。Webサーバーが多くのクライアント接続を処理する場合、プロセスが使用するファイルディスクリプタの数が急増する可能性があります。この設定を適切に調整することで、プロセスが必要なリソースを適切に管理し、システム全体のパフォーマンスを向上させることができます。</li><li><code>worker_processes</code>は、Nginxサーバーが起動するときに生成されるワーカープロセスの数を設定するための設定です。Nginxは、クライアントリクエストを処理するために複数のプロセスを使用します。ワーカープロセスは、クライアントの接続を受け取り、リクエストを処理してレスポンスを返します。この設定は、Webサーバーの処理能力とリソース使用量を制御するために非常に重要です。</li><li><code>worker_connections</code>は、各ワーカープロセスが同時に処理できるクライアント接続の最大数を制御するための設定です。この設定を上げることで、Webサーバーが同時に多数のクライアント接続を処理できるようになります。ただし、この設定が高すぎる場合、プロセスのリソース使用量が増加し、サーバー全体のパフォーマンスが低下する可能性があります。したがって、この設定を適切に調整することが重要です。</li></ul> うん。とりあえず手動かそっか💕

Nginxの設定ファイル

こいつは簡単にいうとNginxのプロセスが開けるファイルディスクリプタの最大数。<blockquote>ファイルディスクリプタとは、オープンされたファイル、ソケット、パイプなどのリソースへの参照を表す整数値です。プログラムがファイルを開いたり、ソケットを作成したりすると、それぞれのファイルディスクリプタが返されます。このファイルディスクリプタを使用して、プログラムはファイルやリソースにアクセスし、読み書きや通信を行います。</blockquote>まずはこいつの適正値を求めていこう↓ 1, nginxのサーバーのOSの扱えるファイルの最大値を確認<pre><code>cat /proc/sys/fs/file-max
392069</code></pre> ※なんで確認するの？ファイルディスクリプタを設定する際OSで扱える以上を設定すると、NginxでOSで扱えない量のファイル数を参照しエラーになってNginx落ちちゃうお。参考) https://please-sleep.cou929.nu/nginx-too-many-open-files-error.html 2, wokerプロセス数を設定する。worker_processの設定値は下記がベスト。CPUのスペックに合わせてよしなにprocess数を設定してくれる。<pre><code>worker_processes auto;</code></pre> 3, wokerプロセス数を確認する。<pre><code># ps -ef | grep nginx
root&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1&nbsp; &nbsp; &nbsp;0&nbsp; 0 08:08 ?&nbsp; &nbsp; &nbsp; &nbsp; 00:00:00 nginx: master process nginx -g daemon off;
nginx&nbsp; &nbsp; &nbsp; &nbsp;35&nbsp; &nbsp; &nbsp;1&nbsp; 0 08:08 ?&nbsp; &nbsp; &nbsp; &nbsp; 00:00:00 nginx: worker process
nginx&nbsp; &nbsp; &nbsp; &nbsp;36&nbsp; &nbsp; &nbsp;1&nbsp; 0 08:08 ?&nbsp; &nbsp; &nbsp; &nbsp; 00:00:00 nginx: worker process
nginx&nbsp; &nbsp; &nbsp; &nbsp;37&nbsp; &nbsp; &nbsp;1&nbsp; 0 08:08 ?&nbsp; &nbsp; &nbsp; &nbsp; 00:00:00 nginx: worker process
nginx&nbsp; &nbsp; &nbsp; &nbsp;38&nbsp; &nbsp; &nbsp;1&nbsp; 0 08:08 ?&nbsp; &nbsp; &nbsp; &nbsp; 00:00:00 nginx: worker process
nginx&nbsp; &nbsp; &nbsp; &nbsp;39&nbsp; &nbsp; &nbsp;1&nbsp; 0 08:08 ?&nbsp; &nbsp; &nbsp; &nbsp; 00:00:00 nginx: worker process
root&nbsp; &nbsp; &nbsp; &nbsp; 98&nbsp; &nbsp; 88&nbsp; 0 08:40 pts/0&nbsp; &nbsp; 00:00:00 grep nginx</code></pre> 今回でいうと5つ動いてることになりますね。 4, worker_rlimit_nofileを設定するworkerrlimitnofileは workerプロセスの最大オープンファイル数の上限値で、workerプロセス毎の値です。OSの上限は先ほど確認しましたね。少し余裕を持たせて90パーセントにしましょうか。<pre><code>上限値 ÷ worker_process（２） * 0.9
392069 ÷ 5 * 0.9 = 70571...
# 端数を切る
worker_rlimit_nofile　70000;</code></pre> 5, worker_connectionsを設定する<blockquote>この設定は、Nginxが扱える同時接続数を制限するためのもので、worker_connectionsの値はNginxワーカープロセスが同時に接続できるクライアントの最大数を定義します。一方、worker_rlimit_nofileは、Nginxワーカープロセスが同時に開けるファイルディスクリプタの最大数を定義します。</blockquote>さて最後の設定値ですが下記は守っていれば特に問題はないです。<pre><code>worker_connections * 2 &lt; worker_rlimit_nofile</code></pre> ※2ってなんの数字？ファイルディスクリプタを使用するための最小限の値を表します。Nginxワーカープロセスは、各接続に対して少なくとも1つのファイルディスクリプタを使用します。また、一部のモジュールは、追加のファイルディスクリプタを使用する場合があります。 バッファを持って3~4倍でも超えない値を設定するのが良いでしょう。<pre><code>worker_rlimit_nofile 70000; # worker_connections の3~4倍以上の値を設定

events {
 worker_connections 8192; # 1つのworkerプロセスが開ける最大コネクション数
 ...
}

</code></pre> 8192の4倍は32768なので余裕です。 最終的なファイルは下記になります。<pre><code>user nginx;
worker_processes auto;
worker_rlimit_nofile 70000;

events {
 worker_connections 8192;
}</code></pre> Doneです！！

設定値を求める

Nginx

<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/8a2c9ef1752242a9b2823b932f2c124c/image.png" alt=""> A, コンテナのタスク定義で下記を設定する<pre><code>"ulimits": [
 {
 "name": "nofile",
 "softLimit": 100000,
 "hardLimit": 100000
 }
 ]</code></pre>

Q, ECSでNginxコンテナを立てると以下エラーが出る、、、

1, 一旦サーバーに入って確認<pre><code>ulimit -n
100000</code></pre> ん？適用されてね？ということで調べてみた。<blockquote>workerrlimitnofileとECSタスク定義のulimitの設定が競合していない場合、setrlimit(RLIMIT_NOFILE, 100000) failed (1: Operation not permitted)というエラーが発生することはなくなります。そのため、ECSタスク定義の方に適切なulimitの設定を行うことで、問題を解決することができます。ただし、ECSタスク定義のulimitの設定によって、Nginxプロセスが必要とするファイルディスクリプタ数を満たせているかどうかを確認する必要があります。必要なファイルディスクリプタ数がulimitの設定を超える場合は、設定値を調整する必要があります。</blockquote> つまりタスク定義で設定している値とnginx.confで設定している値が競合してエラーが出ていたらしい。どちらか片方を消せばエラーは解消されるが、タスク定義で設定している場合Nginxのプロセスの基準値を考慮する必要があるらしい。<blockquote>両方に設定を行う場合は、workerrlimitnofileとECSタスク定義のulimitで同じ値を設定するようにします。ただし、上記でも述べたように、両方の設定が競合する場合があるため、可能な限りどちらか一方の設定に統一することをお勧めします。</blockquote>nginx.confとタスク定義で同じ値を入れれば特に問題はなし。nginx.confの方にタスク定義と同じ値を記述して対応した。 最後にサーバー上にて確認<pre><code># cat /proc/35/limits
Limit&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Soft Limit&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Hard Limit&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Units
Max cpu time&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; seconds
Max file size&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bytes
Max data size&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bytes
Max stack size&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 10485760&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;10485760&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bytes
Max core file size&nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bytes
Max resident set&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bytes
Max processes&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; processes
Max open files&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 100000&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 100000&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; files
Max locked memory&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bytes
Max address space&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bytes
Max file locks&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; locks
Max pending signals&nbsp; &nbsp; &nbsp; &nbsp;30446&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 30446&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; signals
Max msgqueue size&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;819200&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;819200&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;bytes
Max nice priority&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0
Max realtime priority&nbsp; &nbsp; &nbsp;0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0
Max realtime timeout&nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unlimited&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; us</code></pre> CloudWatchのエラーも消えてulimitsも適用されてるので一旦よし。

BuildersIO produced by YOKU

#AWS の記事一覧

EC2 Instance Connectでコスト削減！プライベートサブネットのEC2に接続してみたよ

mainブランチにマージ→S3にデプロイ→CloudFrontのキャッシュ削除まで自動化してみた

Nuxt.jsをS3にデプロイしてCloudFront経由でアクセスする

AWS CodeCommitからSSH接続でgit cloneする

【AWS】boto3でDynamoDBを操作するときによく使うメソッド

Boto3でDynamoDBのテーブルから複数レコードを一括で削除する

RDS Proxyの負荷検証を行った件について

【Nginx x ECS】Nginxの適正設定値の導き方

【AWS】boto3でDynamoDBを操作するときによく使うメソッド

単体テストのベストプラクティス

Auth0環境を構築して自作のAPIと連携してみた