Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
マルチアーキテクチャ対応のコンテナイメージをちゃんと理解して使いこなす
Search
gree_tech
PRO
October 17, 2025
Technology
520
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
マルチアーキテクチャ対応のコンテナイメージをちゃんと理解して使いこなす
GREE Tech Conference 2025で発表された資料です。
https://techcon.gree.jp/2025/session/TrackB-4
gree_tech
PRO
October 17, 2025
More Decks by gree_tech
See All by gree_tech
1on1、進捗確認だけになっていませんか?〜明日から使えるTips〜
gree_tech
PRO
0
7
AI画像認識を活用したゲーム内決済処理検証の自動化
gree_tech
PRO
0
980
長期運営で肥大化したExcelマスターデータの解消に向けた移行事例
gree_tech
PRO
0
1.1k
ゲームにおけるメディアミックス展開との向き合い方 -ヘブンバーンズレッドのメディアミックス企画の立て方-
gree_tech
PRO
0
1.1k
課題発見から始めるプロダクト密着型TA組織立ち上げ 〜小規模TAチームが3Dアセットの生産性を倍にした方法〜
gree_tech
PRO
0
1.1k
属人化を叩き割れ!「制作加速」と「安定化」の矛盾を打破する:8年目プロダクトが辿り着いた「ミスが起こり得ない」アセット制作フローの全貌
gree_tech
PRO
0
970
20年続く長寿タイトルが、15年目にして売上を伸ばせた理由
gree_tech
PRO
0
1.6k
我々はどう生きるか
gree_tech
PRO
2
1.1k
変わるもの、変わらないもの :OSSアーキテクチャで実現する持続可能なシステム
gree_tech
PRO
0
5.6k
Other Decks in Technology
See All in Technology
Datadog で始める トークンセーフティなAI 導⼊と定着
vkbaba
1
120
あけおめLINE 傾向とその対策
nasa9084
0
340
AIエージェントを安全で速い現場監督にする:Jev・Obsidian・メタハーネス
x5gtrn
PRO
0
140
AIに任せた品質は、誰が見立てるのか - AI時代のテストマネジメント
nakanao
3
3.2k
ScotSecure West 2026 - Glasgow
raybugg
0
190
AI Native Platform Engineering 〜PlatformとAgileで“作る速さ”を“価値”へ〜
uya116
0
350
AWS DevOps Agent スキルをつかいこなそう / Master AWS DevOps Agent Skills
kinunori
2
600
2026-09-08 そのJavaモダナイゼーション、AIに丸投げで大丈夫?IBM Bobで変わる品質と効率
yutanonaka
1
210
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
170
「大丈夫そう?」をObservabilityで確かめる
mrmtsu
0
210
セルフサービスのオブザーバビリティ基盤をOpenTelemetryで作る / Building a Self-Service Observability Platform with OpenTelemetry
ymotongpoo
3
430
JSONataとAWS Step Functionsで目指すRuntimelessな世界
mu7889yoon
1
540
Featured
See All Featured
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
58k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
510
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
360
Tell your own story through comics
letsgokoyo
1
1.1k
Making the Leap to Tech Lead
cromwellryan
135
10k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
35
2.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
409
67k
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
6
1.2k
4 Signs Your Business is Dying
shpigford
187
23k
Transcript
マルチアーキテクチャ対応の コンテナイメージを ちゃんと理解して使いこなす 株式会社 WFS 駒﨑 拓斗
駒﨑 拓斗 組み込みソフトウェア開発会社を経て 2012 年にグリー株式会社 (現:グリーホールディングス株式会社)へ入社。開発基盤やクラ ウドインフラの構築、運用に横断的に携わる。 2023 年からは株式会社WFS にて『アナザーエデン』『ヘブン
バーンズレッド』のバックエンド、運用基盤の開発に従事。 株式会社 WFS リードエンジニア 2
アジェンダ • 背景 • コンテナイメージのマルチアーキテクチャ対応とは • マルチアーキテクチャ対応のためのビルド実例 3
背景 : 身近になった ARM アーキテクチャ • x86 中心だったサーバサイドでも ARM が広がりを見せている
• AWS, Google Cloud での身近な ARM トピック ◦ 2018/11 AWS re:Invent にて ARM ベースプロセッサ Graviton 発表 ◦ 2020/06 AWS Tokyo リージョンで Graviton2 が利用可能に ◦ 2023/02 AWS Tokyo リージョンで Graviton3 が利用可能に ◦ 2024/12 AWS Tokyo リージョンで Graviton4 が利用可能に ◦ 2024/04 Google Cloud Next にて ARM ベースプロセッサ Axion 発表 ◦ 2025/春頃 Tokyo リージョン GKE で Axion ベース VM ノードが利用可能に 4
背景 : 身近になった ARM アーキテクチャ • ARM PC の普及 ◦
サーバサイド & ローカル PC で同じイメージをエミュレーションなしで実行したい ◦ Apple silicon Mac での将来的な x86 エミュレーション提供の不透明さ • x86 / ARM どちらでも利用可能なコンテナイメージが求められる 5 Single-platform images Multi-platform image
WFS サーバサイド開発の CPU 近況 • 開発者 PC ◦ Mac (Apple
silicon) & Windows (Intel & AMD) 混在 • 現行ゲームサービスのゲーム API サーバ ◦ 基本的に x86_64 のみ • 非ゲーム API サーバ、開発環境 ◦ x86_64 & ARM 混在 • 新規開発向けゲームサーバ ◦ x86_64 & ARM 混在 6
ただし書き • マルチアーキテクチャとは題しつつも ◦ x86_64, ARM の 2つを対象にして話します ▪ x86_64
はコード中で amd64 と記載するケースがあります • 本スライド中では基本的に同義です ▪ ARM はコード中で arm64 と記載するケースがあります ◦ 他のアーキテクチャについても外れる話ではないです • コンテナは Linux コンテナのみを扱います 7
ところで? それぞれの矢印でどんなコンテナイメージがやりとりされている? 8 $ docker pull \ hello-world:latest ARM PC
x86 PC $ docker pull \ hello-world:latest $ docker tag \ hello-world:latest \ foobar/hello-world:latest $ docker push \ foobar/hello-world:latest foobar server (registry) ??
コンテナイメージの マルチアーキテクチャ対応とはなにか 9
マルチアーキテクチャ対応のコンテナイメージとは それぞれのアーキテクチャ向けのイメージへの参照が列挙されている イメージインデックス (マニフェストリストとも) 10 https://docs.docker.com/build/building/multi-platform/
コンテナイメージの構造 • OCI (Open Container Initiative) イメージフォーマット仕様にしたがう ◦ マニフェストおよびファイルシステムレイ ヤー、コンフィグ等によって構成されるこ
とを規定する仕様 11 https://github.com/opencontainers/image-spec/blob/v1.1.1/image-layout.md https://github.com/opencontainers/image-spec/blob/v1.1.1/spec.md • ファイルとして出力する際の仕様もある => OCI イメージレイアウト仕様 • docker image save などで出力可能 ◦ 例 docker image save alpine:latest | tar xf -C dir/ blobs/ sha256/ ... index.json oci-layout
レジストリ コンテナイメージの構造 (デフォルメ) イメージの名前は何を指すか? 通常は以下のどちらかを参照して使っている • ファイル実体を持ち実行可能なもの • メタデータだけを持ち、 そこから実行可能なイメージを参照するもの
12 実行可能なイメージ ファイルシステム メタデータ (image.manifest) インデックス メタデータ (image.index) 実行可能なイメージ ファイルシステム メタデータ (image.manifest) 実行可能なイメージ ファイルシステム メタデータ (image.manifest) インデックス メタデータ (image.index) 実行可能なイメージ ファイルシステム メタデータ (image.manifest) ※ いずれも仕様上は広義のイメージですが、 本スライドでは前者をイメージ、 後者をインデックスと呼ぶようにします
マルチアーキテクチャ対応するには • 各アーキテクチャ向けのイメージを作成 • イメージインデックスを作成 ◦ manifests にそれぞれへの参照を含める ▪ platform
ごと ◦ ユーザに参照してもらうためのタグをつける (latest, v2, 1.2.3-alpine, etc.) 13 { "mediaType": "application/vnd.oci. image.index.v1+json", "manifests": [ { "mediaType": "application/vnd.oci. image.manifest.v1+json", "digest": "sha256:<amd64 イメージの digest>", "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:<arm64 イメージの digest>", "platform": { "architecture": "arm64", "os": "linux", "variant": "v8" } } ] } インデックス メタデータ (image.index) ... ... $ docker pull \ hello-world:latest tags: latest
基本的なコマンドを使った作りかた • 各アーキテクチャ向けのイメージを作成し push ◦ ( 図をいれる ) ◦ (
レジストリの状態の画像 ) ◦ ◦ ◦ • イメージインデックスを作成 14 # ARM ホストで $ docker build . \ -t someregistry/myapp:0.1.0-arm64 $ docker push \ someregistry/myapp:0.1.0-arm64 # x86_64 ホストで $ docker build . \ -t someregistry/myapp:0.1.0-amd64 $ docker push \ someregistry/myapp:0.1.0-amd64 # Usage: docker manifest create MANIFEST_LIST MANIFEST [MANIFEST...] $ docker manifest create \ someregistry/myapp:0.1.0 \ someregistry/myapp:0.1.0-arm64 \ someregistry/myapp:0.1.0-amd64
基本的なコマンドを使った作りかた 15
より便利なコマンド • 実用的にはもっとイージーに作成可能 • 例 : docker buildx ◦ 各アーキテクチャ向けにビルドしてインデックス作成し
push ◦ 内容確認 16 $ docker buildx build . \ --platform=linux/amd64,linux/arm64 \ -t someregistry/myapp:0.2.0 \ --push $ docker buildx imagetools inspect someregistry/myapp:0.2.0 Name: someregistry/myapp:0.2.0 MediaType: application/vnd.oci.image.index.v1+json Digest: sha256:c86a1c628af0e47bf09b4c2ad49c68797fa7908822fc16c284f8a52ecf6a2f9c Manifests: Name: someregistry/myapp:0.2.0@sha256:8c8aa16... MediaType: application/vnd.oci.image.manifest.v1+json Platform: linux/amd64 Name: someregistry/myapp:0.2.0@sha256:7aded20... MediaType: application/vnd.oci.image.manifest.v1+json Platform: linux/arm64 ...
※ 注: build の挙動が異なる場合があります • 前述の docker コマンドによるビルド出力は環境により異なります ◦ 2025/09
現在、Docker Desktop では自動的にイメージインデックス+イメージのビルド 結果が得られます (設定依存) ▪ その場合に単一のイメージとしてビルドするには 17 $ docker build . \ --provenance=false \ -t someregistry/myapp:0.1.0-arm64
※ 注: イメージインデックス非対応の環境もあります • コンテナ実行環境によってはインデックス経由の参照に非対応 • AWS Lambda をコンテナイメージで動かす場合 ◦
単一イメージにのみ対応 ( 2025/09 現在 ) https://docs.aws.amazon.com/lambda/latest/dg/nodejs-image.html 18
中間まとめ • コンテナイメージのマルチアーキテクチャ対応は、 各アーキテクチャごとのイメージをたばねた イメージインデックス(マニフェストリスト) によって実現される 19
ビルド実例 20
アーキテクチャ別イメージをどのようにビルドするか 選択肢 • 単一ホスト上でエミュレーションしてビルド ◦ まずはこれを検討 • アーキテクチャ別にホストを用意してビルド ◦ エミュレーション環境利用が困難、またはビルド時間に問題があれば
• クロスコンパイルによるバイナリ生成 ◦ (本発表では割愛 ) golang シングルバイナリのイメージ等 21
エミュレーションによるビルド ローカル PC の例 ※一時的な作業や検証向けに。 Docker Desktop, Podman Desktop :
デフォルトでエミュレーション利用可能 docker-ce : QEMU, buildx-plugin の導入で利用可能 22 $ docker buildx build . \ --platform=linux/amd64,linux/arm64 \ -t someregistry/myapp:0.3.0 \ --push $ podman build . \ --platform=linux/amd64,linux/arm64 \ --manifest someregistry/myapp:0.3.0 \ $ podman manifest push \ someregistry/myapp:0.3.0
エミュレーションによるビルド GitHub Actions の例 標準 GitHub Hosted ランナーで setup actions
を利用 管理コストも低く、広く使われてい ると思われる 23 jobs: build: runs-on: ubuntu-latest steps: ... - name: Set up QEMU uses: docker/setup-qemu-action@v3 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 ... - name: Build and push uses: docker/build-push-action@v6 with: platforms: linux/amd64,linux/arm64 push: true tags: xxx
エミュレーションよしあし • ビルド環境、ワークフローの管理が簡単 • 計算コストが高い場合にパフォーマンス悪化が顕著 ◦ 問題となった事例: PHP gRPC 拡張のインストール
▪ もともと時間のかかる処理だったが QEMU 環境でより顕著に ▪ GitHub Actions, on: ubuntu-latest (x86) • Build linux/amd64: 約10分~ • Build linux/arm64: 約250分~ 24 RUN ... && pecl install grpc-1.x.x 関連: 弊社 藤田によるブログ記事 Github ActionsでCloud Spanner対応のPHPイメージをビルドするための工夫|株式会社 WFS https://note.com/wfs_blog/n/na6adcf9c454f
アーキテクチャごとに別ホストでビルド docker buildx の例 • builder にリモートホストを登録可能 • 対象アーキテクチャごとに 使ってほしいホストを指定する
• push する場合はリモートから registry に疎通可能である必要あり • ローカル書き出しは非サポート (2025/09 現在) 25 $ docker buildx create \ --name multi-node-builder \ --node local \ --platform linux/arm64,linux/arm $ docker buildx create \ --name multi-node-builder \ --append \ --node remote-x86 \ --platform linux/amd64,linux/386 \ ssh://remote-builder-host $ docker buildx use multi-node-builder $ docker buildx build . \ --platform=linux/amd64,linux/arm64 \ -t someregistry/myapp:0.3.0 \ --push
アーキテクチャごとに別ホストでビルド GitHub Actions の例 • x86 用は標準ランナーで • ARM 用には
Self-Hosted ランナー or GitHub Hosted ランナー を使う • GitHub Hosted ランナーは制限あり ◦ public レポ ◦ Enterprise or Team プラン ▪ org 毎に Large Runner として明示的に追加 • それぞれのビルド後に イメージインデックスを作成する ◦ docker buildx imagetools create \ xxx:latest-amd64 \ xxx:latest-arm64 \ --tag xxx:latest 26 jobs: build-x86: runs-on: ubuntu-latest steps: ... - name: Build amd64 uses: docker/build-push-action@v6 with: platforms: linux/amd64 push: true tags: xxx:latest-amd64 build-arm: # Self-hosted runner または org で Large Runner 登録 runs-on: ubuntu-your-arm-runner steps: ... - name: Build arm64 uses: docker/build-push-action@v6 with: platforms: linux/arm64 push: true tags: xxx:latest-arm64
アーキテクチャごとに別ホストでビルド GitHub Actions から AWS CodeBuildの例 • runs-on: codebuild- で
AWS CodeBuild をランナーとして利用可能 27 jobs: build-codebuild-x86: runs-on: codebuild-my-x86-prj-${{ github.run_id }}-${{ github.run_attempt }} steps: ... build-codebuild-arm: runs-on: codebuild-my-arm-prj-${{ github.run_id }}-${{ github.run_attempt }} steps: ... --- # または jobs: build-codebuild: runs-on: - codebuild-my-prj-${{ github.run_id }}-${{ github.run_attempt }} image: arm-3.0 instance-size: small steps: ...
アーキテクチャごとに別ホストでビルド AWS CodePipeline + CodeBuild の例 • イメージビルド用とインデックス用の CodeBuild プロジェクトと
buildspec を用意 • AWS のマネージド機能で完結可能 28
まとめ • コンテナイメージのマルチアーキテクチャ対応 ◦ 各アーキテクチャごとのイメージをたばねた イメージインデックス(マニフェストリスト) によって実現される • アーキテクチャの異なるイメージをビルドするには ◦
エミュレーション or ◦ ネイティブ環境でそれぞれビルドし、インデックスで束ねる • GitHub Actions, AWS を中心とした CI 例の紹介 ◦ 基本手順は同じ ▪ イメージ作成 => インデックス作成 29
ご清聴ありがとうございました 30
None