時間がない人のために先に結論だけ申し上げると、結局ドキュメントに記載のとおりだった。ただ、もう少し付け加えると、無限に多くのリクエストを受けられるわけではなく、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の負荷検証を行った件について

<ul><li>個人情報をサーバーに保存したくない人</li><li>少しでも画像データの削減をしたい人</li></ul>

この記事はこんな人向け

FinderでExif情報がある画像を見ると、こんな感じ。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/eeeef582d0274ea5b4f00f440d8e9a63/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-03-21%2022.34.30.png" alt=""> <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/03171583a01c467a88f41cdc41e274bd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-03-21%2022.34.37.png" alt="">GPSはFinderから消せるけど、他の情報は消せない。。。 画像のように、Exif情報は、画像の向きや撮影したカメラ情報、撮影場所のデータが格納されている。どの画像ファイルにもあるものではなく、JPEG（JFIF/.jpgファイル）あるいはTIFF（.tifファイル）などのファイル形式と共に用いられることが多い。 jsでExif情報の操作をする記事は少ないので苦労しました。みんなどうしているんだろう。。。pythonなどでは、PILを使って画像自体を新規作成したら消せるみたいなこともある様子。 Exif情報には、画像の向きなどの情報も含んでいるので、むやみに消すのは良くない。

Exif情報について詳しく

今回は、<a href="https://github.com/TakeshiOkamoto/EXIF.js" target="_blank" rel="noopener noreferrer">こちら</a>のライブラリを使わせていただきました。中身を見るとわかるのですが、バイナリデータをそのままいじっています。JPEGファイルの構造などは、<a href="https://hp.vector.co.jp/authors/VA032610/JPEGFormat/StructureOfJPEG.htm" target="_blank" rel="noopener noreferrer">こちら</a>を参照ください。 まずは、<a href="https://github.com/TakeshiOkamoto/EXIF.js/blob/master/EXIF.js" target="_blank" rel="noopener noreferrer">EXIF.js</a>を丸々コピーして、assetsフォルダなどの適当なところをに保存します。次に、先程保存したjsファイルをhtml側から呼び出せるように読み込ませます。<pre><code>&lt;script src="assets/EXIF.js"&gt;&lt;/script&gt;</code></pre> あとは、下記のコードをhtml内で動かせばjpegファイルがダウンロードされます。<pre><code>// inputフォームなどから画像データを取得。このあたりはよしなにしてください。
var buffer = event.target.result;

// uint8arrayに変換する。
var uint8Array = new Uint8Array(buffer);

// EXIF object定義。
ExifMaster = new TExifMaster(uint8Array);

// EXIF削除し、画像をダウンロード。
ExifMaster.SaveToFile("test.jpeg", false)</code></pre>

ライブラリを使う

僕は、Exif情報を消したあと、s3にアップロードしたかったので、先程のEXIF.jsに関数を付け足しました。 <pre><code>// -----------------------------------------------------------
// all : true 全てのExifを削除 false 画像方向のみを残す
// -----------------------------------------------------------
SaveToUint8Array: function (all) {
	// uint8arrayオブジェクトが返却される。
	return this.SaveToStream(all, true);
}</code></pre> 呼び出し側は、下記のようにしてみました。<pre><code>var buffer = event.target.result;

var uint8Array = new Uint8Array(buffer);

// EXIF object定義
ExifMaster = new TExifMaster(uint8Array);

// EXIF削除。uint8arrayオブジェクトで取得
const convertedUint8Array = ExifMaster.SaveToUint8Array(false)

// Fileオブジェクトに戻すなどしても良い。
upload_file = new File([convertedUint8Array.buffer], upload_file.name, {type: "image/jpeg"})</code></pre> Exif情報の確認は、TExifMasterを初期化後、Analystプロパティに保存されます。console.logなどで、ご自身が欲しい情報を見つけてみてください。 <pre><code>ExifMaster = new TExifMaster(new Uint8Array(reader.result));

// プロパティ確認用
onsole.log(ExifMaster.Analyst);</code></pre>

ライブラリをカスタマイズしてみる

Exif情報を削除してみる

【javascript】画像に含まれるexif情報を削除する

OpenAPIを<a href="https://swagger.io/" target="_blank" rel="noopener noreferrer">Swagger</a>とか<a href="https://redocly.com/" target="_blank" rel="noopener noreferrer">Redoc</a>でブラウザに表示させながら、書き換えもしたいし、リアルタイムに変更を見たいし、さらにはHTMLを書き出したい時だってあるよね。 そんな時はこの構成でホットリロードとバンドルをしちゃえば運用コスト低めで叶えることができるよね。

tl;dr

はい、いきなり愚痴が出てしまいました。 そうなんです、OpenAPIをゼロから書く時って割とファイル量が多く、着手から10分後くらいには途方もなさを感じてメンブレ必至です。 既存APIの実装からOpenAPI形式で仕様を書き出すツール等ありますが、初期整備として仕様書を書く際はゼロから書かなければいけないケースが大半かと思います。 前述していますが、OpenAPIは細かい仕様を書くことができる。だからこそ、完成度の高い仕様書を作成するとなると必然的にファイル量は増えてしまいます。

ゼロから書いていくのは割と辛い。

何かしらの仕様に変更や誤りがあったり、単純に誤字していることに気が付いたり。 いざ実装を進めていると、細かいことにも気が付くようになり、多少なり仕様書を書き換えることがあります。 「仕様書を見ていつつも、書き換えもしたい」そんなニーズです。

ちょっと修正したい時だってある。

これはOpenAPIの強みの一つなので、僕にとってファイル分割は必ず採用したいものです。（というより、OpenAPIを一つのファイルで書ききるのは鬼の所業…。） そして、分割されたファイルを一つにバンドルしておきたい。一つのファイルにまとまっていると、何かと便利です。 例えば、<ul><li>ファイルのPath指定による<code>$ref</code>はSwaggerだと上手くいくが、Redocだと上手く参照できずエラーになる。</li><li>OpenAPIをHTMLにしてチーム内で見れるようにホスティングしたいが、分割されていると上手くHTML出力ができない。</li></ul>みたいなケース。（使っているツールに依る部分もあるかと思います。） こんなケースをカバーするためにも、一つのファイルになっていると恩恵を受けることがあります。

ファイル分割は絶対にしたい。でもバンドルもしたい。

OpenAPIに対する悩み

前置きが長くなってしまいました。さて、前述のお悩み解決に対処する方法です。 ポイントはズバリ二つ。<ol><li>ホットリロード</li><li>分割されたファイルのバンドル</li></ol>

以下の内容で構成していきます。今回はDockerでRedocとして表示させるので、Redocの公式イメージを使います。 <ul><li>Docker<ul><li><a href="https://hub.docker.com/r/redocly/redoc/" target="_blank" rel="noopener noreferrer">Redoc公式イメージ</a></li><li>OpenAPIを編集するための作業スペース</li><li>開発中に表示させて確認する</li></ul></li><li>JavaScriptスクリプト<ul><li>OpenAPIのウォッチャー<ul><li><a href="https://github.com/paulmillr/chokidar" target="_blank" rel="noopener noreferrer">paulmillr / chokidar</a></li></ul></li><li>バンドラー<ul><li><a href="https://github.com/WindomZ/swagger-merger" target="_blank" rel="noopener noreferrer">WindomZ / swagger-merger</a></li></ul></li></ul></li><li>OpenAPI</li></ul>

Dockerでレンダリング & ホットリロード & バンドル

<pre><code>/
├── compose.yaml # Docker Compose
├── docker
│&nbsp; &nbsp;└── redoc
│&nbsp; &nbsp; &nbsp; &nbsp;├── Dockerfile
│&nbsp; &nbsp; &nbsp; &nbsp;├── bundle.ts # バンドラー
│&nbsp; &nbsp; &nbsp; &nbsp;└── start.sh # Docker EntryPoint
└── api_docs/ # 分割されまくったOpenAPIたち
 &nbsp; &nbsp;├── components/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;├── parameters/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── path/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── query/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── requestBodies/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── responses/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── schemas/
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;├── xxx.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;│&nbsp; &nbsp;└── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;└── securitySchemes/
 &nbsp; &nbsp;│&nbsp; &nbsp; &nbsp; &nbsp;├── xxx.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp; &nbsp; &nbsp;└── index.yaml
 &nbsp; &nbsp;├── paths/
 &nbsp; &nbsp;│&nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;│&nbsp; &nbsp;└── xxx/
 &nbsp; &nbsp;│── tags
 &nbsp; &nbsp; │&nbsp; └── xxx.yaml
 &nbsp; &nbsp;├── index.yaml
 &nbsp; &nbsp;└── openapi.yaml # バンドルされたOpenAPI</code></pre>

ディレクトリ構成

<pre><code>version: "3.8"

	services:
	 redoc:
	 build:
	 context: .
	 dockerfile: ./docker/redoc/Dockerfile
	 volumes:
	 - ./docker/redoc/bundle.ts:/app/bundle.ts
	 - ./docker/redoc/start.sh:/app/start.sh
	 - ./api_docs:/usr/share/nginx/html/docs # Redoc公式イメージでは '/usr/share/nginx/html/' 配下にOpenAPIを置く必要がある
	 ports:
	 - 9000:80</code></pre>

compose.yaml

<pre><code># Redoc公式イメージをベースに
FROM redocly/redoc:v2.0.0
	
WORKDIR /app
	
# ホットリロードにnpmパッケージを使用するためnpmインストール
RUN apk add --no-cache npm
	
# npmパッケージをコンテナ内でしようするための設定
ARG NODE_MODULE_PATH=/node
RUN npm config set prefix=${NODE_MODULE_PATH}
ENV PATH $PATH:${NODE_MODULE_PATH}/bin
ENV NODE_PATH ${NODE_MODULE_PATH}/lib/node_modules
	
# レンダリングするOpenAPIのPath　（Redoc公式イメージの環境変数）
# ファイル分割された '$ref' が含まれていると上手く参照できずエラーになる
# そのため、バンドル前の 'index.yaml' は使わず、バンドルされたファイルを指定する
ENV SPEC_URL docs/openapi.yaml
	
# ホットリロードに使用するnpmパッケージ群をインストール
RUN npm i -g \
 forever \
	ts-node \
	chokidar \
	swagger-merger
	
# EntoryPointにShellスクリプト指定
ENTRYPOINT [ "sh", "start.sh" ]</code></pre>

docker/redoc/Dockerfile

<pre><code># RedocのNginxを立ち上げる
# 'docker/redoc/Dockerfile'の 'ENTRYPOINT' で公式イメージの ' ENTRYPOINT ' は上書きされてしまったので再定義
# '&amp;' を付けてバックグラウンドプロセスにして、後述のバンドラーのプロセスと並走できるようにする
source /usr/local/bin/docker-run.sh &amp;
	
# バンドラー実行
ts-node bundle.ts</code></pre>

docker/redoc/start.sh

<pre><code>// 'ts-ignore' 連発。非常に良くないので反面教師で。。。
// @ts-ignore
const chokidar = require("chokidar") // ウォッチャー
// @ts-ignore
const swaggerMerger = require("swagger-merger") // バンドラー

const rootPath = "/usr/share/nginx/html/docs/" // OpenAPIが置かれているPath
const rootFile = `${rootPath}index.yml` // OpenAPIのルートファイルPath
const mergedFile = `${rootPath}openapi.yml`　　// バンドルしたOpenAPIを吐き出すPath
	
chokidar
 .watch(rootPath, { ignored: mergedFile })
 .on("all", (event: string, path: string) =&gt; {

 // ウォッチャーの検知したイベントをログに出力
 console.log(event, path)

 // OpenAPIをバンドル
 swaggerMerger({ input: rootFile, output: mergedFile })
 .then(() =&gt; {
 	 console.log("ReBundled OpenAPI")
 })
 	.catch((err: object) =&gt; {
	 console.error(err)
	 })
	})</code></pre>

docker/redoc/bundle.ts

この悩みに対処しよう

<ul><li>レンダリング<ul><li>Dockerを立ち上げればRedocをブラウザで確認することができます。</li><li>API実装中には必須だと思います。</li></ul></li><li>ホットリロード<ul><li>OpenAPIを書き換えたらRedocもそのタイミングで更新されます。<ul><li>表示を確認しながらサクサク書くことができます。</li></ul></li><li>「変な表示になってないかな？」「API実装中だけどちょっと修正しとこ。」ができます。</li></ul></li><li>バンドル<ul><li>OpenAPIを書き換えたら一つのOpenAPIとしても書き出されます。</li><li>これさえあれば色んな用途で柔軟に使い回せます。</li></ul></li></ul>

これで何が起こるか (まとめ)

今回はOpenAPIにまつわる開発体験の向上を軸にご紹介しました。割と良くある構成なのかな？とも思いますし、ツールの選定によってはもっとシンプルにすることができるかと思います。 もっと良い構成をご紹介できるように、チャンスがあれば色々試していきたいと思います。 最後まで読んでくださりありがとうございました！では！ﾉｼ

終わりに

OpenAPIの運用コスト下げたい。

<code>MatterArea.tsx</code><pre><code>import {
 Engine,
 Body,
 Render,
 Bodies,
 MouseConstraint,
 Mouse,
 Runner,
 Composite,
} from 'matter-js'
import { memo, useLayoutEffect } from 'react'
import styles from '@/styles/components/MatterArea.module.scss'

export const MatterArea = memo(() =&gt; {
 useLayoutEffect(() =&gt; {
 // イベントリスナー クリーンアップ関数で呼ぶため先に定義
 let scrollTimer: NodeJS.Timeout

 function initMatter(matterHolder: HTMLElement) {
 const engine = Engine.create()
 const width = matterHolder?.clientWidth
 const height = matterHolder?.clientHeight

 const render = Render.create({
 element: matterHolder,
 engine,
 options: {
 width: width,
 height: height,
 background: 'transparent',
 wireframes: false,
 pixelRatio: 5,
 },
 })

 // 壁の追加
 Composite.add(engine.world, [
 Bodies.rectangle(width / 2, height + 250, width, 500, {
 isStatic: true,
 label: '_noMap',
 render: {
 fillStyle: 'transparent',
 },
 }),
 Bodies.rectangle(-50, height / 2, 100, height * 20, {
 isStatic: true,
 label: '_noMap',
 render: {
 fillStyle: 'transparent',
 },
 }),
 Bodies.rectangle(width + 50, height / 2, 100, height * 20, {
 isStatic: true,
 label: '_noMap',
 render: {
 fillStyle: 'transparent',
 },
 }),
 ])

 matterHolder
 .querySelectorAll('[data-object]')
 .forEach((object: HTMLImageElement) =&gt; {
 if (object.getAttribute('data-circle')) {
 addObjectCircle(object)
 } else {
 addObject(object)
 }
 })

 function addObjectCircle(object: HTMLImageElement) {
 const objWidth = object.clientWidth
 const objHeight = object.clientHeight
 let rect: Body

 rect = Bodies.circle(
 Math.random() * (width - 200) + 100,
 -300,
 objWidth / 2,
 {
 label: object.getAttribute('data-object'),
 // density:
 // object.getAttribute('data-object') === 'obj2' ? 0.01 : 0.02, // 質量
 // frictionAir: 0.01, // 空気抵抗
 restitution: 0.75, // 跳ね返り
 friction: 0.01, // 摩擦
 render: {
 sprite: {
 texture: `${object.getAttribute('src')}`,
 xScale: objWidth / object.naturalWidth,
 yScale: objWidth / object.naturalWidth,
 },
 },
 }
 )

 Composite.add(engine.world, rect)
 }

 function addObject(object: HTMLImageElement) {
 const objWidth = object.clientWidth
 const objHeight = object.clientHeight
 let rect: Body

 rect = Bodies.rectangle(
 Math.random() * (width - 200) + 100,
 -300,
 objWidth,
 objHeight,
 {
 label: object.getAttribute('data-object'),
 // density: 2, // 質量
 // frictionAir: 0.01, // 空気抵抗
 restitution: 0.75, // 跳ね返り
 friction: 0.01, // 摩擦
 render: {
 sprite: {
 texture: `${object.getAttribute('src')}`,
 xScale: objWidth / object.naturalWidth,
 yScale: objHeight / object.naturalHeight,
 },
 },
 }
 )

 Composite.add(engine.world, rect)
 }

 if (window.innerWidth &gt;= 768) {
 const mouse = Mouse.create(render.canvas)
 const mouseConstraint = MouseConstraint.create(engine, {
 mouse: mouse,
 constraint: {
 render: {
 visible: false,
 },
 },
 })
 render.mouse = mouse
 Composite.add(engine.world, mouseConstraint)
 }

 Render.run(render)
 const runner = Runner.create()
 Runner.run(runner, engine)

 matterHolder.classList.add('is-active')

 // スクロールで物体を動かす
 scrollTimer = setTimeout(() =&gt; {
 const allBodies = Composite.allBodies(engine.world)
 const scrollY = window.scrollY

 const scrollEvent = () =&gt; {
 const scrollDelta = window.scrollY - scrollY
 // console.log(scrollDelta)

 allBodies.forEach((body: Matter.Body) =&gt; {
 if (body.label === '_noMap') {
 return
 }

 if (Math.floor(scrollDelta) % 5 === 0) {
 Body.applyForce(
 body,
 { x: body.position.x, y: body.position.y },
 {
 x:
 (Math.floor(Math.random() * 2) === 0 ? -1 : 1) *
 Math.random() *
 0.01,
 y: -0.047,
 }
 )
 }
 })
 }

 if (typeof window === 'object') {
 // 画面内だけでスクロールイベント発生
 if (window.IntersectionObserver) {
 const observer = new IntersectionObserver((entries) =&gt; {
 for (const e of entries) {
 if (e.isIntersecting) {
 window.addEventListener('scroll', scrollEvent)
 } else {
 window.removeEventListener('scroll', scrollEvent)
 }
 }
 })
 const observerEl = document.querySelector('#observer')
 observer?.observe(observerEl)
 }
 }
 }, 2000)

 // リサイズが終了して1秒後に削除
 let timeoutId: NodeJS.Timeout
 let windowW = window.innerWidth
 window.addEventListener('resize', () =&gt; {
 if (
 window.innerWidth &gt;= 768 ||
 (window.innerWidth &lt;= 767 &amp;&amp;
 Math.abs(windowW - window.innerWidth) &gt; 5)
 ) {
 clearTimeout(timeoutId)

 timeoutId = setTimeout(function () {
 const allBodies = Composite.allBodies(engine.world)
 allBodies.forEach((body) =&gt; {
 Composite.remove(engine.world, body)
 })
 Engine.clear(engine)
 Runner.stop(runner)
 }, 1000)
 }
 })
 }

 const matterHolder: HTMLElement =
 document.querySelector('[data-html-matter]')

 if (typeof window === 'object') {
 // 画面内で物理エンジンを実行
 if (window.IntersectionObserver) {
 const observer = new IntersectionObserver((entries) =&gt; {
 for (const e of entries) {
 if (e.isIntersecting) {
 if (!matterHolder.classList.contains('is-active')) {
 initMatter(matterHolder)
 }
 } else {
 // console.log('out');
 }
 }
 })

 const observerEl = document.querySelector('#observer')
 observer.observe(observerEl)
 }
 }

 // リサイズが終了して1秒後に再生成
 // safariは過剰にresizeイベントが発火されるのでそれ対策
 let timeoutId: NodeJS.Timeout
 let windowW = window.innerWidth
 const initMatterResize = () =&gt; {
 if (
 window.innerWidth &gt;= 768 ||
 (window.innerWidth &lt;= 767 &amp;&amp; Math.abs(windowW - window.innerWidth) &gt; 5)
 ) {
 clearTimeout(timeoutId)

 timeoutId = setTimeout(function () {
 initMatter(matterHolder)
 }, 1000)
 }
 }

 window.addEventListener('resize', initMatterResize)

 return () =&gt; {
 Engine.clear
 Runner.stop
 window.removeEventListener('resize', initMatterResize)
 clearTimeout(scrollTimer)
 }
 }, [])

 return (
 &lt;&gt;
 &lt;div className={`${styles.matter}`} data-html-matter&gt;
 &lt;div className={`${styles.observer}`} id='observer'&gt;&lt;/div&gt;
 &lt;img
 className={`${styles.logo}`}
 src='/images/top/matter/logo.svg'
 data-object='obj1'
 data-circle
 alt=''
 /&gt;
 &lt;img
 className={`${styles.team}`}
 src='/images/top/matter/team.svg'
 data-object='obj2'
 data-circle
 alt=''
 /&gt;
 &lt;img
 className={`${styles.yoku}`}
 src='/images/top/matter/yoku.svg'
 data-object='obj3'
 alt=''
 /&gt;
 &lt;img
 className={`${styles.build}`}
 src='/images/top/matter/build.svg'
 data-object='obj4'
 alt=''
 /&gt;
 &lt;img
 className={`${styles.member}`}
 src='/images/top/matter/member.svg'
 data-object='obj5'
 alt=''
 /&gt;
 &lt;img
 className={`${styles.product}`}
 src='/images/top/matter/product.svg'
 data-object='obj6'
 alt=''
 /&gt;
 &lt;img
 className={`${styles.service}`}
 src='/images/top/matter/service.svg'
 data-object='obj7'
 alt=''
 /&gt;
 &lt;/div&gt;
 &lt;/&gt;
 )
})

MatterArea.displayName = 'MatterArea'</code></pre> <code>MatterArea.module.scss</code><pre><code>@use '../variable' as v;
@use '../mixin.scss' as r;

.observer {
 position: absolute;
 top: 50%;
 left: 50%;
 transform: translate(-50%, -50%);
 width: 1px;
 height: 1px;
 opacity: 0;
 pointer-events: none;
}

.matter {
 width: 676rem;
 height: 500rem;
 background-color: #fff;
 border-radius: 20px;
 overflow: hidden;
 position: relative;

 canvas {
 position: absolute;
 z-index: 1;
 left: 50%;
 bottom: 0;
 width: 100%;
 height: 100%;
 transform: translateX(-50%);
 background-color: transparent;
 }

 [data-object] {
 position: absolute;
 border-radius: 5px;
 background: rgba(0, 0, 0, 0.05);
 pointer-events: none;
 opacity: 0;

 * {
 pointer-events: all;
 }
 }

 [data-object='obj1'],
 [data-object='obj2'] {
 border-radius: 50%;
 }

 @include r.mq(mdless) {
 border-radius: 0;
 width: 390rem;
 height: 500rem;
 margin-left: -28rem;
 margin-top: -156rem;
 }
}</code></pre> 少し長いですが、全体像はこんな感じです。cssはCSS Modulesであててます。読めば大体わかるはずなので、肝心なところを取り上げて説明します。

全体のソースコード

Matter.jsは、ブラウザのDOMのレンダリングサイクルのタイミングに合わせて、物理エンジンのアニメーションを実行する必要があります。 Reactでは、useEffectはレンダリング後に実行されるため、物理エンジンのアニメーションが描画される前に実行されてしまう可能性があります。これにより、描画される前に計算された位置に物理オブジェクトが表示されたり、描画が一時停止したりするなどの問題が発生する可能性があります。 一方、useLayoutEffectは、ReactがDOMのレンダリング前に呼び出す関数であり、物理エンジンのアニメーションを描画する前に実行されます。これにより、物理エンジンが正確な位置でアニメーションされることが保証されます。

useEffect内ではなくuseLayoutEffect内で実行する

<pre><code>return () =&gt; {
 Engine.clear
 Runner.stop
 window.removeEventListener('resize', initMatterResize)
 clearTimeout(scrollTimer)
}</code></pre> 上記のクリーンアップ関数内で物理エンジンをクリアしたり、イベントリスナー、タイマーを除去してます。アンマウントされる際にリソースの解放を行う必要があるのでこれは大事な処理です。

クリーンアップ関数を書く

Reactで動かすためにすること

パフォーマンス改善のために、画面内でのみ物理エンジンを実行するようにしました。<pre><code>if (typeof window === 'object') {
 // 画面内で物理エンジンを実行
 if (window.IntersectionObserver) {
 const observer = new IntersectionObserver((entries) =&gt; {
 for (const e of entries) {
 if (e.isIntersecting) {
 if (!matterHolder.classList.contains('is-active')) {
 initMatter(matterHolder)
 }
 } else {
 // console.log('out');
 }
 }
 })

 const observerEl = document.querySelector('#observer')
 observer.observe(observerEl)
 }
}</code></pre> <a href="https://developer.mozilla.org/ja/docs/Web/API/Intersection_Observer_API" target="_blank" rel="noopener noreferrer">Intersection Observer API</a>を使います。#observerの要素が画面に入ってきてるかどうかで判定しています。[data-html-matter]の要素に<code>.is-active</code>がついてない時に、<code>initMatter</code>を実行してます。initMatterの関数内で.is-activeが付くので、2回目以降は実行されないようにしています。

画面内でのみ物理エンジンを実行する

<pre><code>const allBodies = Composite.allBodies(engine.world)
const scrollY = window.scrollY

const scrollEvent = () =&gt; {
 const scrollDelta = window.scrollY - scrollY

 allBodies.forEach((body: Matter.Body) =&gt; {
 if (body.label === '_noMap') {
 return
 }

 if (Math.floor(scrollDelta) % 5 === 0) {
 Body.applyForce(
 body,
 { x: body.position.x, y: body.position.y },
 {
 x:
 (Math.floor(Math.random() * 2) === 0 ? -1 : 1) *
 Math.random() *
 0.01,
 y: -0.047,
 }
 )
 }
 })
}</code></pre> <code>allBodies.forEach</code>でWorld内の要素をループで回します。<code>scrollDelta</code>でスクロール幅を計算してます。スクロールのスピードはブラウザで確認しながら調整しました。<code>Body.applyForce</code>で要素を動かすことができます。y軸は固定ですが、x軸はランダムに動くようにしました。<code>Math.floor(scrollDelta) % 5 === 0</code>ちなみにこれ←を書かないと要素が無限に上に消えていきます。(ここは調整)

スクロールで要素が動くようにする

<pre><code>const render = Render.create({
 element: matterHolder,
 engine,
 options: {
 width: width,
 height: height,
 background: 'transparent',
 wireframes: false,
 pixelRatio: 5,
 },
})</code></pre> 画質が悪い場合、<code>pixelRatio: 5</code>を指定すれば治ります。解像度の設定ですね。高く設定しすぎると端末が対応していなくてmatter.jsの表示自体されなくなるので注意です。

画質が悪い場合にすること

時間がなくてかなり駆け出しで説明しましたが、分からないところや聞きたいこと、間違いなどがあればTwitterなどで何なりと聞いてください。

まとめ

物理エンジンライブラリ「matter.js」を使って要素が動くリッチなアニメーションを作ってみた

(...なんかみんな当たり前に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も適用されてるので一旦よし。

Q, 上記やってもまだ同じエラーが出る、、、、

Tips

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

<pre><code>* {
 outline: 1px solid red;
}</code></pre> なんとこれを全体のcssに書くだけ。下記の画像のようにはみ出てる要素が一目瞭然！<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/53c8aa53b7174c28bb395fedf0b14963/image.png" alt=""> <code>overflow: hidden</code>をつけて無事修正完了。

みなさんブックマーク必須です

一瞬で原因がわかるcssがある！

スマホ表示で画面が横スクロールする現象の画期的な原因調査方法

とはいえ、自分のマシンで動かすだけの書き捨てスクリプトなら、書き慣れた言語でサクッと作っちゃう方が良いと思います。 僕の場合、メンバーに依頼されて作ることが殆どなので、どんなPCでも動くべきという課題があります。過去にPythonを使ってスクレイピングをしまくってた時期があるので、Pythonが一番サクッと書けるのですが、<blockquote>使うメンバーに、いちいちPythonインストールさせるのはダサすぎない？</blockquote>という問題がありました。 そんな時にGo。バイナリにしちゃえばターミナルで動きます。そしてクロスコンパイルでLinux・Mac・Windowsなんでもこい、強し。方法としても、buildコマンドで実行環境を指定するだけという簡単なもの。（対応している環境もかなり種類があります。よかったら調べてみてください。） これにより、Slack上でバイナリを配布するだけでみんな使えちゃいます。 Goは後発の言語なので、「イマドキ技術でスクレイピングできる」っていう称号も付きます。

クロスコンパイルがいい感じ

言語はGo

スクレイピングを実行するときって、検索ワードを受け入れる必要があるケースが多いです。また、膨大な数のスクレイピングを一気にブン回しちゃうと相手方のサーバーに迷惑をかけることになるので、例えば特定のカテゴリー別に分けて、必要分のデータだけを対象にする必要もあります。 つまり、ターミナル入力の受付を実装する必要があります。 そんな時にSurveyというパッケージが輝きます。<a href="https://github.com/go-survey/survey" target="_blank" rel="noopener noreferrer">go-survey/survey</a> 超簡単に色んなターミナル入力が実装できちゃいます。初めて出会った時は感動しました。。。 Nuxt.jsプロジェクトを立ち上げる<code>npx create-nuxt-app</code>を実行したときに出るような選択式の入力もできて優秀です。（凝った実装をしてるように見えるので、コスパ良く名声を得ることもできます。）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/b3c367c931474500bff81839c9898845/68747470733a2f2f7468756d62732e6766796361742e636f6d2f4772696d46696c746879416d617a6f6e706172726f742d73697a655f726573747269637465642e676966.gif?w=1000&amp;h=179" alt="">

CLIからの入力はSurvey

生のGoでWebサーバー作るときによく使われるアイツです。この<code>net/http</code>パッケージの<code>Client()</code>をスクレイピングで使います。 同じく<code>net/http</code>に入っている<code>cookiejar</code>を併せて使えば、Cookieを持たせることができます。サイトによってはCookieに値を保持できないとリクエストが通らないケースがあるのですが、これで解決です。<pre><code>import (
	"net/http"
 "net/http/cookiejar"
)

func initClient() *http.Client {
		jar, err := cookiejar.New(nil)
		if err != nil {
			log.Fatalln(err)
		}
		return &amp;http.Client{Jar: jar}
}</code></pre>

HTTPクライアントはnet/http

WebAPIから直接JSONとしてレスポンスを受けることができれば、スクレイピングの必要はありません。リクエスト投げて、レスポンスのJSONをGoの構造体にバインドして処理するだけです。（この方法はブラックに近いグレーだと思うけど。） しかし、スクレイピングはHTML形式のレスポンスとの戦い。そんな時にhtmlqueryをよく使います。<a href="https://github.com/antchfx/htmlquery" target="_blank" rel="noopener noreferrer">antchfx/htmlquery</a> レスポンスとして受け取ったHTMLを与えて、そのままHTMLを要素探索するだけです。無駄なくシンプルに、データの取り出しまでを行うことができます。 <a href="https://developer.mozilla.org/ja/docs/Web/XPath" target="_blank" rel="noopener noreferrer">XPath</a>による探索ができるのが有難いです。ブラウザで実際のページで検証しながら、XPathをポチポチ組んでいます。 XPathを使えばハニーポットトラップも回避できます。でも、ハニーポットを仕掛けているサイトはスクレイピングされることを良しとしていないケースが多いので、スクレイピングをする前に、サイトの規約を確認しましょう…！

「Content-Type: text/html」

HTMLパースはhtmlquery

結果として、以下のような構成が出来上がります。至極一般的な構成のような気もしていますが、どうなんでしょうかね？ <ol><li>ターミナル上でGo製のバイナリ実行</li><li><a href="https://github.com/go-survey/survey" target="_blank" rel="noopener noreferrer">Survey</a>でターミナル入力</li><li><a href="https://pkg.go.dev/net/http" target="_blank" rel="noopener noreferrer">net/http</a>のClientでレスポンス受け取り</li><li><a href="https://github.com/antchfx/htmlquery" target="_blank" rel="noopener noreferrer">htmlquery</a>でHTMLから値取得</li><li>CSV形式でファイルを作成して吐き出し</li></ol> （しかしまぁ、そろそろサイトごとに組まずに汎用化しようかな。。）

Macにて、Slack上でバイナリを渡したときに出るこれ。検証されていないために、素直には実行できない。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/5c41e2c88a2a4113b7c00492a9ccbb58/image.png?w=350&amp;h=369" alt=""> バイナリに署名とかできるものなのかね？実行する方法はあるから特に調査せず、それで問題なしとしてるけども。良い感じの方法あったらまた記事にします。 読んでいただきありがとうございました！ﾉｼ

課題

Goでスクレイピングするときによく使う構成まとめてみた

みなさん、初めまして！株式会社YOKU 取締役の新井です。 今月からようやくYOKUのメンバーのブログがスタートします。メンバーは全員書いてくれるらしいです！感謝！ 普段、社内Slackのtimesチャンネルで書いてあることをもうちょっと細かく言語化してもらいます。（社内ではGo / TypeScript / AWSを中心に開発をしているのでその辺が中心になるかと！） 今後、最新の技術に関して情報を発信していきますので、よろしくお願いします！

BuildersIO produced by YOKU

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

【javascript】画像に含まれるexif情報を削除する

OpenAPIの運用コスト下げたい。

物理エンジンライブラリ「matter.js」を使って要素が動くリッチなアニメーションを作ってみた

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

スマホ表示で画面が横スクロールする現象の画期的な原因調査方法

Goでスクレイピングするときによく使う構成まとめてみた

YOKUブログ始めました！

Docker+Go+GinのAPI開発環境を5分で作る

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

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