面倒なのは嫌なのでコンテナのマネージドサービスの極振りしたいと思います。

Slide 1

Slide 1 text

for PHPerKaigi 2023 面倒なのは嫌なのでコンテナのマネージドサービスに極振りしたいと思います。 2023年3月25日 (土) 株式会社Nextat 中榮健二 Nextat Inc. 1

Slide 2

Slide 2 text

自己紹介 from 京都 - 中榮健二（なかえけんじ） - twitter: @n_1215　 - 株式会社Nextat 取締役 - Webアプリのバックエンドがメインのはず。インフラ専任ではない - ここ最近はWebフロントエンドやUnityを使ってクライアント側をやったり PHP以外の仕事も増加 Nextat Inc. 2

Slide 3

Slide 3 text

発表概要 1. 本発表の前提 2. コンテナベースのPaaSの特徴と具体例 3. PHPとコンテナベースのPaaS 4. DBサーバの選択肢 5. 頻出処理におけるサービス・機能の選択 6. デプロイ周りの話 7. その他トピック 8. まとめ Nextat Inc. 3

Slide 4

Slide 4 text

1. 本発表の前提 Nextat Inc. 4

Slide 5

Slide 5 text

想定する聴衆の例インフラ保守のコスト（人的コストを含む）を減らしたい楽にWebアプリケーションをデプロイしたい AWS App RunnerやGoogle Cloud Runに興味はあるが手は出していない Herokuからの移行先を探している Amazon ECSは業務で利用しているが設定が大変なので他の方法を探している HTTP APIの実装にAWS Lambdaを使ったことがあるが辛みがあった Nextat Inc. 5

Slide 6

Slide 6 text

PaaS（Platform as a Service）と CaaS（Container as as Service） Cloud Run や App RunnerもCaaS（Container as a Service）と呼んで良いのではと思っていたが、Google Cloudのドキュメントによると https://cloud.google.com/learn/paas-vs-iaas-vs-saas?hl=ja CaaS: GKE PaaS: GAE、Cloud Run とのこと Nextat Inc. 6

Slide 7

Slide 7 text

極振りしたいコンテナのマネージドサービスとは本資料でメインに扱うコンテナのマネージドサービスは DockerfileやBuildpacks（後述）の設定だけすれば良い感じにコンテナとして Webアプリを動かしてくれるサービスコンテナベースのPaaS と分類するのが良さそう CaaS は Container Runtime as a Service くらいのニュアンスかなと思っていたが、 Container Orchestrator as a Service のほうが近そう Amazon ECSはCaaSで良い？セッションのタイトルにCaaSと入れてなくてよかった Nextat Inc. 7

Slide 8

Slide 8 text

そもそもコンテナとは仮想化の一種 OSは共有し、ハードウェアは仮想化しないハイパーバイザ型の仮想化（ex. Hyper-V、VirtualBox）に比べ軽量でリソース利用の効率が良いホストOSの他のプロセスからの隔離＋リソース制限ポータビリティ（可搬性）が高い Build, Ship and Run Any App, Anywhere by Docker 本番環境に近い構成をローカル環境で再現しやすい Nextat Inc. 8

Slide 9

Slide 9 text

https://academy.gmocloud.com/vps/20211228/13893 より Nextat Inc. 9

Slide 10

Slide 10 text

Open Container Initiative https://opencontainers.org/ コンテナランタイム・コンテナイメージフォーマットの標準策定のため設立 Linux Foundationプロジェクトの一つコンテナランタイムの例 runc: 広く利用されているリファレンス実装。containerd（を利用する Docker）やcri-oのランタイムとして利用 kata-runtime: 軽量VMで高い安全性を志向するKata Containersのランタイム runsc: 高い安全性を志向するGoogleのgVisorのランタイム Nextat Inc. 10

Slide 11

Slide 11 text

Dockerイメージと OCIイメージ OCIの策定した仕様に準拠するコンテナイメージをOCIイメージと呼ぶ OCIイメージであればOCI準拠のコンテナランタイムで動かせる OCIイメージというインターフェースへの依存 OCIの標準化にはDockerが大きく貢献資料内ではDockerイメージという用語よりコンテナイメージという用語を多く使いますが、OCIイメージのことだと思ってください蛇足： OCI だけで検索するとOracleのクラウドがヒットしやすいので注意 Nextat Inc. 11

Slide 12

Slide 12 text

Build/Share/Run 元々Build/Ship/Runだったが最近は Ship → Share としている模様 https://www.docker.com/ Build: コンテナイメージの作成コンテナのビルドツールを利用 Share: コンテナイメージの保管と共有コンテナレジストリを利用脆弱性検証なども含むが今回は触れない Run: コンテナとして動作コンテナランタイムを利用今日はこの3つのステージのうち、BuildとRunの話がメイン Nextat Inc. 12

Slide 13

Slide 13 text

コンテナをビルドするツールの選択肢 OCIイメージは必ずしもDockerfileを使ってビルドされるとは限らない Cloud Native Buildpacks（以下Buildpacks or CNBとも呼称） Bazel: https://bazel.build/?hl=ja Jib（Java用）: https://github.com/GoogleContainerTools/jib Nixpacks（Railwayのプロジェクト）: https://nixpacks.com/docs/getting- started 本日紹介するコンテナ系マネージドサービスのデプロイパイプラインはDockerfileないしBuildpacksに対応している場合が多い Nextat Inc. 13

Slide 14

Slide 14 text

Cloud Native Buildpacks https://buildpacks.io/ アプリケーションのソースコードからOCIイメージを作成するツールベストプラクティスが多すぎる Dockerfile からの解放セキュアなイメージを共有したい PHPの場合はHerokuのBuildpacksが使いやすい HerokuのBuidlpacksからCNBは標準化されたので元祖とも言える Herokuで使われているイメージが手元でも再現できる GCPでもGoogle Cloud BuildpacksとしてBuildpacksをサポートしているただしPHPには非対応 Nextat Inc. 14

Slide 15

Slide 15 text

HerokuのBuildpackでLaravelアプリのイメージを作成する例 Procfile: 起動処理はnginxとApacheを選択可 web: heroku-php-nginx -C nginx.conf public nginx.conf: nginxの設定 location / { try_files $uri @rewriteapp; } location @rewriteapp { rewrite ^(.*)$ /index.php$1 last; } Nextat Inc. 15

Slide 16

Slide 16 text

project.toml: Buildpacksの設定ファイル [project] id = "my-laravel-app" name = "My Laravel Application" version = "1.0.0" [build] exclude = [ "/README.md", ".git", "/vendor", "/node_modules" ] builder = "heroku/buildpacks:20" [[build.buildpacks]] uri = "heroku/php" [[build.buildpacks]] uri = "heroku/procfile" [[build.buildpacks]] uri = "heroku/nodejs" Nextat Inc. 16

Slide 17

Slide 17 text

composer.json: PHPのバージョンとPHP拡張はcomposer.jsonから読み取って自動で設定される { "require": { "php": "8.2.0", "ext-apcu": "*" } } package.json: ビルド時にJSのアセットを生成 { "scripts": { "heroku-postbuild": "npm run production" }, } Nextat Inc. 17

Slide 18

Slide 18 text

packコマンドを打つと指定した名前のコンテナイメージが生成される pack build my-laravel-app docker runでコンテナを起動できる docker run --rm -e PORT=8080 -p 8080:8080 my-laravel-app Dockerfileの場合より少し記述は散らばるが、PHP拡張の依存までは気にする必要がなくなる ext-grpc が入らない、ARM対応していないなどの一部制限はある参考 Dockerfile不要！Cloud Native BuildpacksでLaravelアプリケーションのコンテナイメージを作成する https://nextat.co.jp/staff/archives/266 Nextat Inc. 18

Slide 19

Slide 19 text

2. コンテナベースのPaaSの特徴と具体例 Nextat Inc. 19

Slide 20

Slide 20 text

PaaS（Platform as a Service）の良いところサービス提供側にサーバ・ミドルウェアの管理を任せられるスケーリングも任せられる特にGAE/SEはスケーラビリティが高いアプリケーション開発に集中できる Nextat Inc. 20

Slide 21

Slide 21 text

非コンテナベースのPaaSの辛いところ運用の労力低減と自由度の高さはトレードオフ PHPバージョンの自由度が低い GAE: なかなかPHPのバージョンが上がらなかった時期がある PHP拡張の自由度が低かったり扱いがわかりにくかったり Heroku: Buildpackだとext-grpcが使えない GAE: ext-sodiumの使い方が難解独自の制限 GAE: 1ディレクトリの下に1000ファイルまでローカル開発での環境再現に難ありインフラの費用自体はIaaS（VM）に比べて高くなりがち ※ 人的コストまで入れて比較すべき Nextat Inc. 21

Slide 22

Slide 22 text

FaaS（Function as a Service）の良いところイベントドリブンなアーキテクチャに適しているリクエストを処理している時間だけに課金無料枠も大きい場合が多いスケーラビリティが高い（スパイクにとても強い）スケーラビリティ重視の場合やインフラコスト削減への強い要望がある場合に AWS縛りの中のLambdaは強力な選択肢 ECS/FargateやApp Runnerはスケールの初速が遅い＋完全にはゼロスケールしない（待機状態でも課金される） Nextat Inc. 22

Slide 23

Slide 23 text

FaaS（+PHP）の辛いところ普段慣れているアプリケーション開発の構成を変える必要がある FaaS特有の知識が必要になるので必要なインフラ知識が増えるローカルでの再現に難あり FaaSごとに統一性がない AWS Lambda PHPには公式では非対応なのでカスタムランタイムを使う必要がある Bref (https://bref.sh/)を使えば楽ができるが、一つ間接層が増える Google Cloud Functions PHPに公式対応しているが、GAEと同じくPHPバージョンとPHP拡張の自由度低 Nextat Inc. 23

Slide 24

Slide 24 text

コンテナベースのPaaS 非コンテナベースのPaaSとCaaSの間くらいの立ち位置非コンテナベースのPaaSより自由度は高いが、コンテナやミドルウェアの存在は意識する必要がある CaaSほど設定が複雑ではないが自由度は低いコンテナイメージを自由にカスタマイズできる PHPのバージョンやPHP拡張を自由にコントロールコンテナを動かすために裏側で使われる技術スタックは様々だが、コンテナイメージというインターフェースは共通コンテナ依存なのでローカル環境での再現性が高い Amazon ECSのサービスのようにコンテナを複数まとめた単位では扱えない場合が多いので、コンテナのサイドカーなどは使えない Nextat Inc. 24

Slide 25

Slide 25 text

例1 Heroku 老舗のPaaSとして知られるが、裏はコンテナベース HerokuのBuildpackはCloud Native Buildpacksに準拠している Dockerイメージとコンテナレジストリを用いたデプロイも可能 https://devcenter.heroku.com/ja/categories/deploying-with-docker Nextat Inc. 25

Slide 26

Slide 26 text

例2 Render https://render.com/ Buildpacksには対応していないがDockerfile対応リージョンは今の所シンガポールが日本から近い。東京対応予定はある様子 https://feedback.render.com/features/p/tokyo-region Nextat Inc. 26

Slide 27

Slide 27 text

例3 Fly.io https://fly.io/ アクセスしたユーザに近いリージョンでサービス（コンテナ）を実行するという一風変わったPaaS。CDNに近い発想 Buildpacks・Dockerfile対応パブリックなDockerイメージの指定可 AWS Lambda/Fargateと同じFirecracker VMを利用 https://firecracker- microvm.github.io/ Nextat Inc. 27

Slide 28

Slide 28 text

例4 Railway https://railway.app/ Buildpacks・Dockerfile・Nixpacks対応管理画面のUIがよく出来ているとの評判リージョンはUSのみだがAsia対応予定はある模様 https://blog.railway.app/p/scaling-railway-roadmap Nextat Inc. 28

Slide 29

Slide 29 text

例5 Koyeb https://www.koyeb.com/ コンテナレジストリからのデプロイに対応 Buildpacks対応まだ発展途上でリージョンも少ないが複数リージョンが選択できるなど面白そう裏は Firecracker VM + Nomad + Kuma Nextat Inc. 29

Slide 30

Slide 30 text

例6 Cloud Run https://cloud.google.com/run?hl=ja Dockerfile対応 Google Cloud BuildpacksというCNB準拠な仕組みがあるがPHPは非対応実体はマネージドKnative: https://cloud.google.com/knative?hl=ja FaaSと同じく料金含めゼロスケールするのが特徴カナリアリリースなど機能が充実 Nextat Inc. 30

Slide 31

Slide 31 text

例7 AWS App Runner https://aws.amazon.com/jp/apprunner/ マネージドランタイムはPHP 8.1に対応。当初ビルトインウェブサーバを使っていたが最近nginx/Apache+PHP-FPM構成にも対応 https://github.com/aws/apprunner-roadmap/issues/157 ECRからのデプロイを選択すればコンテナイメージを自由にカスタムできる裏は ECSと同じFargate 比較的新しいサービスだが、最低限の機能は揃ってきた PHPerKaigi 2023 でも 3/23(木) day0 に @seike460 さんのセッションあり https://speakerdeck.com/seike460/my-continued-use-of-aws- lambda-php-production-explores-the-potential-of-aws-app-runner Nextat Inc. 31

Slide 32

Slide 32 text

3. PHPとコンテナベースのPaaS Nextat Inc. 32

Slide 33

Slide 33 text

PHPとコンテナベースのPaaS 複数コンテナをまとめた単位で扱えないため、1コンテナでHTTPサーバとなる方が都合が良い 1コンテナにWebサーバとPHP-FPM または Apache httpd + mod_phpとなることが多い前者は1コンテナ1プロセスの教えには反するが、Herokuで実績は十分ある使い分け基準の例 APIサーバ専用 → オーバーヘッドが少ない Apache httpd + mod_php 静的アセット配信も兼ねる → nginx + PHP-FPM 速さが足りない → RoadRunner、Swoole、ReactPHP、AMPHP etc. ビルトインウェブサーバーは本番ではダメ絶対 Nextat Inc. 33

Slide 34

Slide 34 text

1コンテナに複数プロセスラッパースクリプトかプロセスマネージャ（supervisordなど）を利用する Run multiple services in a container https://docs.docker.com/config/containers/multi-service_container/ HerokuのBuildpacksの場合 nginx + PHP-FPM or Apache httpd + PHP-FPM をProcfileで指定それぞれ起動スクリプトが用意されている App RunnerのPHPマネージドランタイムの場合 supervisordは自力で追加する形での対応。ラッパースクリプトによる方法も紹介されている https://docs.aws.amazon.com/ja_jp/apprunner/latest/dg/service- source-code-php.html Nextat Inc. 34

Slide 35

Slide 35 text

4. DBサーバの選択肢 Nextat Inc. 35

Slide 36

Slide 36 text

DBサーバをどうする？ DBサーバのコストは全体に占める割合が比較的高いので重要自前管理は面倒なのでマネージドなサービスを使いたい PaaSのサービスはRDBMSやRedisにも対応していることが多いクラウドプロバイダのコンテナ系PaaSを使う場合は、同一プロバイダ内で済ませるのが一番楽外部のDBaaSを使うのも一手自由度の制限はあることに注意。特にPostgreSQL率が割と高い今回はNoSQL系DBの話はしません Nextat Inc. 36

Slide 37

Slide 37 text

PaaS付属のRDB Render: PostgreSQL https://render.com/docs/databases Fly.io: PostgreSQL https://fly.io/docs/postgres/ Railway: PostgreSQL / MySQL https://docs.railway.app/databases/postgresql https://docs.railway.app/databases/mysql Nextat Inc. 37

Slide 38

Slide 38 text

クラウドプロバイダのマネージドRDBサービス AWS: Amazon RDS、Aurora、Aurora Serverless https://aws.amazon.com/jp/rds/ https://aws.amazon.com/jp/rds/aurora/ https://aws.amazon.com/jp/rds/aurora/serverless/ GCP: Cloud SQL、AlloyDB for PostgreSQL、Cloud Spanner https://cloud.google.com/sql?hl=ja https://cloud.google.com/alloydb?hl=ja https://cloud.google.com/spanner?hl=ja DBをプライベートなVPCに配置する場合は追加で設定が必要 App Runner: VPCエンドポイント、Cloud Run: サーバレスVPCアクセス Nextat Inc. 38

Slide 39

Slide 39 text

DBaaS系の外部サービス外部のマネージドなDBサービスを利用する手もあるサーバレスDB、Cloud Database Platformなどとも呼ばれる Koyebの記事： https://www.koyeb.com/blog/which-cloud-database- platform-to-choose-for-your-applications Nextat Inc. 39

Slide 40

Slide 40 text

DBaaSの例 Supabase Postgres https://supabase.com/docs/guides/database/overview Supabase自体は Backend as a Service DigitalOcean https://www.digitalocean.com/products/managed-databases DigitalOcean自体はDBaaSというよりはクラウドプロバイダ最寄りRegionはシンガポール Aiven（アイベン） https://aiven.io/ja MySQL、PostreSQL、 Redis、OpenSearch etc. AWS、Azure、GCP、DigitalOceanなどクラウドやリージョン間の移行が可能 Nextat Inc. 40

Slide 41

Slide 41 text

DBaaSの例（続き） Crunchy Bridge https://www.crunchydata.com/products/crunchy-bridge PostgreSQL で有名な Crunchy Data AWS、Azure、GCP Neon https://neon.tech/ マルチクラウドなマネージドPostgreSQL 最寄りRegionはシンガポール Nextat Inc. 41

Slide 42

Slide 42 text

NewSQL系のDBaaSの例 https://ja.wikipedia.org/wiki/NewSQL 従来のデータベースシステムのACID特性を維持しながら、オンライントランザクション処理（OLTP）の作業負荷に対してNoSQLシステムのスケーラビリティを提供しようとするリレーショナルデータベース管理システムの一種である PlanetScale（MySQL互換） https://planetscale.com/ YugabyteDB Managed（PostgreSQL互換） https://www.yugabyte.com/managed/ CockroachDB serverless（PostgreSQL互換） https://www.cockroachlabs.com/get-started-cockroachdb/ Nextat Inc. 42

Slide 43

Slide 43 text

NewSQL系のDBaaSの例（続き） TiDB Cloud（MySQL互換） https://pingcap.co.jp/tidb-cloud/ MySQL8系には未対応 TiDBは日本でもソーシャルゲーム業界などで採用の兆し https://speakerdeck.com/cygames/zui-gao-nokontentu-wozhi- eru-cygamesnodetabesuji-shu-nojin-madetokorekara-ci-shi-dai- detabesu-tidb-nojian-zheng-wokai-shi-sitacygamesnoqu-rizu-mi 注1: New SQL系のサービスはサービスによっては例えば auto incrementが連番にならない、主キーはUUIDv4推奨など元のRDBMSにはない制限がある場合がある注2: PaaSや同一クラウドプロバイダのDBサービスを使う場合に比べ、DBaaSはレイテンシの問題が出る場合があるので、利用時は実際に計測推奨 Nextat Inc. 43

Slide 44

Slide 44 text

Redis 用途が多いのでとりあえず構成に入れておきがちセッションストアセッションストアにもRDBを使う手もあるが負荷が上がると厳しいキャッシュストアコンテナローカルなキャッシュでも良ければAPCuという手もあるロック（排他制御）これはRDBでもできる非同期処理時のメッセージのキューイング・Pub/Sub こちらもRDBでも代替可マネージドサービスで冗長構成にすると地味に料金が高い負荷が上がった時のスケーリングの辛み Nextat Inc. 44

Slide 45

Slide 45 text

PaaS付属のRedis Redis®* | Render · Cloud Hosting for Developers https://render.com/docs/redis Redis | Railway Docs https://docs.railway.app/databases/redis The Redis database service uses the bitnami/redis:6.0 docker image. Nextat Inc. 45

Slide 46

Slide 46 text

クラウドプロバイダのマネージドRedis AWS: ElastiCache for Redis https://aws.amazon.com/jp/elasticache/redis/ AWS: Amazon MemoryDB for Redis https://aws.amazon.com/jp/memorydb/ Redis互換 + 耐久性・高可用性 GCP: Cloud Memorystore for Redis https://cloud.google.com/memorystore?hl=ja Redis Enterprise Cloud（AWS/GCP/Azure対応） https://redis.com/redis-enterprise-cloud/overview/ Nextat Inc. 46

Slide 47

Slide 47 text

DBaaSのRedis（サーバレスRedis） Upstash: Serverless Data for Redis® and Kafka® https://upstash.com/ Fly.io は Upstash推奨の様子 https://fly.io/docs/reference/redis/ 日本リージョンあり（AWSのap-northeast-1） Momento（サーバレスキャッシュ） https://jp.gomomento.com/ 少しずれるが他のサービスがあまり見当たらなかったので紹介 Redis互換のためのproxyがある模様 https://github.com/pelikan- io/pelikan/blob/main/src/proxy/momento/README.md Nextat Inc. 47

Slide 48

Slide 48 text

5. 頻出処理におけるサービス・機能の選択 Nextat Inc. 48

Slide 49

Slide 49 text

5-1. 非同期処理（メッセージのキューイング）キューやPub/Subの仕組みを使ってその場で処理する必要のない処理や重い処理をバックグランドで実行レスポンスを早く返せる例）メール送信 Push型とPull型の２種類の構成がある Nextat Inc. 49

Slide 50

Slide 50 text

https://www.tencentcloud.com/document/product/406/4791 より Nextat Inc. 50

Slide 51

Slide 51 text

Push型 Consumer側でHTTPエンドポイントを用意するのが一般的メリットリアルタイム性コストデメリット Pushした時点でConsumerが落ちていないことを要求リトライやデッドレターキューなどでカバーはできる Pushする側がConsumerについて知っている必要がある ProducerのほうがConsumerより性能が高い場合にあふれる可能性がある Nextat Inc. 51

Slide 52

Slide 52 text

Pull型 Consumer側がworkerを起動させてポーリングするメリット一時Consumerがダウンしていたとしてもメッセージが棄却されない Consumer側の処理性能が低い場合でも流量調整が必要ないデメリットリアルタイム性が低くなる場合あり Worker常駐のコストポーリング間隔の調整が必要な場合も Nextat Inc. 52

Slide 53

Slide 53 text

選択肢1) Redis Pub/Sub https://redis.io/docs/manual/pubsub/ Redisを使ってPub/Subのメッセージングができる Redisを使った非同期処理ではよく採用されている Nextat Inc. 53

Slide 54

Slide 54 text

選択肢2) Redis Streams（Redis >= 5.0） https://redis.io/docs/data-types/streams/ データを時系列に格納する追記用のデータ構造 Consumerが落ちていても後から参照できるデータを取得して以降も揮発しない参考 Redis Streams tutorial | Redis https://redis.io/docs/data-types/streams-tutorial/ マイクロサービスを支えるメッセージング技術：Redis Streams https://zenn.dev/nitaking/articles/e5bdaa4605b637 Redis Streamsを活用したイベントドリブンアーキテクチャの構築事例 https://inside.dmm.com/articles/games-redis-cluster/ Nextat Inc. 54

Slide 55

Slide 55 text

選択肢3) RDBのSKIP LOCKEDを使う PostgreSQL >= 9.5 MySQL >= 8.0.1 で SKIP LOCKED が追加 SELECT FOR UPDATE の際に別のトランザクションで行ロックされているレコードを除外する事が可能 → キュー用途に使ってもデッドロックが起きない＋パフォーマンスの向上が期待できる Nextat Inc. 55

Slide 56

Slide 56 text

SKIP LOCKEDの参考 MySQL :: MySQL 8.0.1: Using SKIP LOCKED and NOWAIT to handle hot rows https://dev.mysql.com/blog-archive/mysql-8-0-1-using-skip-locked- and-nowait-to-handle-hot-rows/ What's new in PostgreSQL 9.5 - PostgreSQL wiki https://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.5#SKIP _LOCKED PostgreSQLのSKIP LOCKEDを使ってテーブルをキューとして使用する - Enjoy*Study https://blog.enjoyxstudy.com/entry/2017/09/10/000000 Nextat Inc. 56

Slide 57

Slide 57 text

例） LaravelのキューのDBドライバーパフォーマンスに関しては最高ではないが、本番でも使えるレベルになっているとのこと I've tested the changes processing 516,783 jobs by 50 workers and it resulted no deadlocks. A production-ready database queue driver for Laravel - Diving Laravel https://divinglaravel.com/a-production-ready-database-queue-diver- for-laravel Nextat Inc. 57

Slide 58

Slide 58 text

選択肢4) PostgreSQLのLISTEN/NOTIFYを使う LISTEN / NOTIFY https://www.postgresql.org/docs/current/sql-listen.html https://www.postgresql.org/docs/current/sql-notify.html Pub/Subの仕組み参考 PostgreSQL でメッセージキューイングを行う(LISTEN, NOTIFY) https://symfoware.blog.fc2.com/blog-entry-2519.html Do You Really Need Redis? How to Get Away with Just PostgreSQL https://spin.atomicobject.com/2021/02/04/redis-postgresql/ Nextat Inc. 58

Slide 59

Slide 59 text

例） Symfony の Messengerコンポーネントトランスポート（≒メッセージの伝送路）として、DoctrineとPostgreSQLを使う設定が可能舞台裏では、SymfonyはPostgreSQLに組み込みの、高速で、スケーラブルで、トランザクションできる pub/sub システム(LISTEN/NOTIFY)を利用しています。メッセージの保存先としてPostgreSQLの代わりにRabbitMQを使いたい場合は、RabbitMQの章を読んでみてください。参考非同期にする (Symfony 6.2 Docs) https://symfony.com/doc/6.2/the-fast-track/ja/18-async.html Nextat Inc. 59

Slide 60

Slide 60 text

選択肢5) クラウドプロバイダのマネージドサービス Amazon SQS (Pull型) https://aws.amazon.com/jp/sqs/ Amazon SNS（Push型） https://aws.amazon.com/jp/sns/ Cloud Pub/Sub（PushとPullを選択可） https://cloud.google.com/pubsub/docs/overview?hl=ja Cloud Tasks（Push型） https://cloud.google.com/tasks?hl=ja Cloud Tasks か Pub/Sub かの選択 https://cloud.google.com/tasks/docs/comp-pub-sub?hl=ja Nextat Inc. 60

Slide 61

Slide 61 text

選択肢6) 自前のコンテナでサービスを立てる ※ あまりおすすめはしない RabbitMQ https://www.rabbitmq.com/ Fly.ioのコミュニティでは試している方々がいた https://community.fly.io/t/rabbitmq-on-fly-io/5510 Apache ActiveMQ https://activemq.apache.org/ Nextat Inc. 61

Slide 62

Slide 62 text

メッセージのConsumer Pull型の場合はキューワーカー用のコンテナを常駐させるのが基本 Webアプリケーションからキューワーカーまで全部入りのコンテナにする手もあるがメモリとコンテナの常駐化が必要なことには注意 Consumerの処理速度を上げるにはバッチ取得を使うかコンテナを増やす App Runnerは今の所は常駐設定がない（Lambdaを挟んでHTTPリクエストを投げる構成は可能だが、この場合も実行時間上限がネック） Push型の場合は認証付きのHTTPエンドポイントを用意するのが手軽 Webアプリケーションと同じコンテナを使える＋スケーリングも楽 Nextat Inc. 62

Slide 63

Slide 63 text

PaaSのキューワーカー機能の例 Background Workers | Render · Cloud Hosting for Developers https://render.com/docs/background-workers Cron and Queues · Fly Docs https://fly.io/docs/laravel/the-basics/cron-and-queues/ 単にワーカー用のコンテナを起動する Nextat Inc. 63

Slide 64

Slide 64 text

5-2. 定時処理選択肢1) 常駐コンテナでcronを動かす Cron and Queues · Fly Docs https://fly.io/docs/laravel/the-basics/cron-and-queues/ 選択肢2) PaaS 組み込みのスケジューラー Heroku Scheduler | Heroku Dev Center https://devcenter.heroku.com/ja/articles/scheduler Cron Jobs | Render https://render.com/docs/cronjobs Nextat Inc. 64

Slide 65

Slide 65 text

定時処理（続き）選択肢3) スケジューラー + HTTPエンドポイント Amazon EventBridge（API Destinations） + App Runner https://aws.amazon.com/jp/eventbridge/ App Runnerの実行時間の上限が低い(120秒)のがネック Cloud Schduler + Cloud Run https://cloud.google.com/scheduler?hl=ja Cloud Runは実行時間が柔軟。デフォルト5分、最長60分選択肢4) スケジューラー + コンテナ起動 Amazon EventBridge + ECS Task https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide /scheduled_tasks.html Cloud Schduler + Cloud Run Jobs https://cloud.google.com/run/docs/execute/jobs-on-schedule Nextat Inc. 65

Slide 66

Slide 66 text

定時処理（続き）スケジューラーを使う場合は常駐のコンテナは節約できるが、起動スケジュールの定義がPHPアプリの外部になるのをどう管理するかが問題になる例）Laravelのタスクスケジュール https://laravel.com/docs/10.x/scheduling use Illuminate\Console\Scheduling\Schedule; $schedule->command('emails:send') ->hourly() ->days([Schedule::SUNDAY, Schedule::WEDNESDAY]); Nextat Inc. 66

Slide 67

Slide 67 text

5-3. 画像やファイルのアップロード処理オブジェクトストレージ PaaSの対応 Render Feature RequestsでPLANNEDとはなっているが2023年中は進展なさそう https://feedback.render.com/features/p/cloud-object-storage Deploy MinIO Object Storage to Fly.io · Fly Docs https://fly.io/docs/app-guides/minio/ S3互換のMinIOをコンテナで立てる + Fly Volume Storage に永続化コンテナへの極振りっぷりが清々しい Nextat Inc. 67

Slide 68

Slide 68 text

クラウドプロバイダのオブジェクトストレージのサービス Amazon S3 https://aws.amazon.com/jp/s3/ Google Cloud Storage https://cloud.google.com/products/storage?hl=ja Cloudflare R2 S3互換、エグレス料金ゼロのオブジェクトストレージ https://www.cloudflare.com/ja-jp/products/r2/ Nextat Inc. 68

Slide 69

Slide 69 text

6. デプロイ周りの話 Nextat Inc. 69

Slide 70

Slide 70 text

デプロイパイプラインマネージドの場合ほとんどソースコードだけを気にしていれば良いせいぜいDockefileないしCloud Native Buildpacksの設定のみ App RunnerのマネージドランタイムやCloud RunのGoogle Cloud Buildpacksを用いたデプロイもこちら自前の場合デプロイスクリプトないしビルド設定ファイルを書くコンテナイメージをビルドしてレジストリにプッシュする処理がメイン App Runner: AWS CodeBuild/CodePipeline + Elastic Container Registry Cloud Run: Cloud Build + Artifact Registry Nextat Inc. 70

Slide 71

Slide 71 text

デプロイパイプラインへの介入 DBのマイグレーションなど、デプロイ時に行いたい処理はあるもの自前定義の場合はコマンドを直接書けば済むデプロイパイプラインがマネージドの場合、苦し紛れの設定としてはコンテナの起動処理に入れこむ手もあるが…… Nextat Inc. 71

Slide 72

Slide 72 text

リリースコマンド Fly.ioはrelease_commandという設定がある https://fly.io/docs/reference/configuration/#run-one-off-commands- before-releasing-a-deployment [deploy] release_command = "php artisan migrate" RenderはリリースコマンドのFeature RequestがあるがPLANNED https://feedback.render.com/features/p/release-phase-script Nextat Inc. 72

Slide 73

Slide 73 text

コマンドを実行するその他の方法 SSH接続などを介してコンテナでコマンドを実行できる場合もある無料プランでサポートされていない場合もあるので注意例 Connecting with SSH | Render https://render.com/docs/ssh Fly sshコンソール https://fly.io/docs/flyctl/ssh-console/ fly ssh console -C "php /var/www/html/artisan migrate --force" Nextat Inc. 73

Slide 74

Slide 74 text

コマンドを実行するその他の方法（続き） ECS Task、Cloud Run Jobsなどでコンテナを実行 Cloud RunのDBマイグレーションどうする問題にCloud Runジョブで対処する - Qiita https://qiita.com/okonomi/items/b885c22e3dae4153f67d HTTPエンドポイントから実行定時処理同様に、DBマイグレーションコマンドを実行できる認証ありの HTTPエンドポイントを生やしておく手もあるデプロイと別タイミングでマイグレーションを実行する場合は、Feature Flagなどデプロイとリリースのタイミングをずらす仕組みを使うと安全デプロイ → DB マイグレーション → フラグを有効化して新機能リリース Nextat Inc. 74

Slide 75

Slide 75 text

7. その他トピック Nextat Inc. 75

Slide 76

Slide 76 text

プライベートサービスの構成アクセス元の制限やユーザーが直接アクセスしないサービスの構成に利用 Private Services | Render · Cloud Hosting for Developers https://render.com/docs/private-services AWS App Runner が Amazon VPC 内のプライベートにアクセス可能なサービスのサポートを開始 https://aws.amazon.com/jp/about-aws/whats-new/2022/11/aws-apprunner-supports-privately-accessible-services-amazon-vpc/ プライベートネットワークと Cloud Run https://cloud.google.com/run/docs/securing/private-networking? hl=ja Nextat Inc. 76

Slide 77

Slide 77 text

静的サイトの配信極振りからは少し外れるが、静的サイトの配信をしたい場合はコンテナにこだわらないほうが良い場合がある PaaS付属の静的サイトホスティング機能 Fly.ioはGoの静的アセット用Webサーバをコンテナで立てるという極振りオブジェクトストレージ + CDN S3 + CloudFront Cloud Storage + Cloud CDN Cloudflare R2 + Workers 外部の静的サイトホスティングサービス Cloudflare Pages、Firebase Hosting、GitHub Pages etc. Nextat Inc. 77

Slide 78

Slide 78 text

WebSocketやHTTP/2、gRPC対応サポート状況はまちまちなので使う予定がある場合は選定時に調べると良い Cloud Run: サポート済 https://cloud.google.com/blog/ja/products/serverless/cloud-run-gets- websockets-http-2-and-grpc-bidirectional-streams App Runner: 未サポート https://github.com/aws/apprunner-roadmap/issues/13 https://github.com/aws/apprunner-roadmap/issues/77 Fly.io: サポート済 https://fly.io/blog/websockets-and-fly/ https://fly.io/docs/app-guides/grpc-and-grpc-web-services/ Nextat Inc. 78

Slide 79

Slide 79 text

ARM対応 Apple Silicon搭載Macの登場でコンテナのポータビリティに若干の疑問符今回資料で取り上げたサービスはARM対応していないはずなので、手元の環境と差異が出る可能性がある今回対象ではないがAWS FargateはLinux/ARMに対応（Graviton2）しており、ARMのほうが時間あたりの価格は安い https://aws.amazon.com/jp/fargate/pricing/ 裏が同じFargateのApp Runnerは早めに対応しそうな気はする https://github.com/aws/apprunner-roadmap/issues/98 Nextat Inc. 79

Slide 80

Slide 80 text

8. まとめ Nextat Inc. 80

Slide 81

Slide 81 text

まとめコンテナベースのPaaSは従来のPaaSとCaaSの中間くらいのサービスコンテナイメージというインターフェースに依存する事で移植性・PHP実行環境の柔軟性・エコシステムの有効活用が期待できる PHPでもコンテナベースのPaaSと各種マネージドサービスを組み合わせて運用コストを下げていこう主観によるおすすめ度現状でのおすすめはCloud Run。「Cloud Runはいいぞ」次点にUIが優しく機能も一通り揃ったRender Fly.ioはやや玄人好み。コンテナへの極振りにかけてはお前がナンバーワンだ App Runnerも最近改善が目覚ましい。後は常駐のワーカーに対応すればなんとでもなる Nextat Inc. 81

Slide 82

Slide 82 text

PR: ITエンジニアを募集しています株式会社Nextat https://nextat.co.jp 受託開発業務システム、ECサイト、スマホアプリ、VR... 本社は京都ですが、東京・名古屋・北海道・島根などフルリモート勤務実績あり設計の話に付き合ってくれる方大歓迎！ Nextat Inc. 82

Slide 83

Slide 83 text

ご清聴ありがとうございました Nextat Inc. 83