Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチアーキテクチャ対応のコンテナイメージをちゃんと理解して使いこなす
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
gree_tech
PRO
October 17, 2025
Technology
360
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
変わるもの、変わらないもの :OSSアーキテクチャで実現する持続可能なシステム
gree_tech
PRO
0
4.6k
マネジメントに役立つ Google Cloud
gree_tech
PRO
0
60
今この時代に技術とどう向き合うべきか
gree_tech
PRO
3
2.7k
生成AIを開発組織にインストールするために: REALITYにおけるガバナンス・技術・文化へのアプローチ
gree_tech
PRO
0
420
安く・手軽に・現場発 既存資産を生かすSlack×AI検索Botの作り方
gree_tech
PRO
0
410
生成AIを安心して活用するために──「情報セキュリティガイドライン」策定とポイント
gree_tech
PRO
1
2.2k
あうもんと学ぶGenAIOps
gree_tech
PRO
0
530
MVP開発における生成AIの活用と導入事例
gree_tech
PRO
0
560
機械学習・生成AIが拓く事業価値創出の最前線
gree_tech
PRO
0
430
Other Decks in Technology
See All in Technology
AI Engineering Summit Tokyo 2026 AIの前に、やることがある 〜医療データ企業の4フェーズ〜
dtaniwaki
0
2.5k
2026TECHFRESH畢業分享會 - 葬送的通靈師:化系統與用戶雜訊成行動訊號
line_developers_tw
PRO
0
670
Agentic ERPをどう設計するか ー 受発注エージェントを動かす、現場の知見と設計思想ー
recerqainc
1
2.2k
攻撃者視点で考えるDetection Engineering
cryptopeg
0
570
Dario Amodi『Policy on the AI Exponential』を理解する
nagatsu
0
210
データサイエンスを価値につなげるプロジェクト設計 〜 DS一年目が現場で得た気づき 〜
ysd113
1
110
EventBridge Connection
_kensh
5
690
小さくはじめるSLI/SLO ~育てながら組織に定着させる実践知~ / Starting Small with SLI/SLOs: Building Adoption Through Continuous Growth
nari_ex
2
1.3k
On-behalf-of Token exchange with AgentCore Identity
hironobuiga
2
140
新規事業を牽引する技術選定 〜フルスタックTypeScript開発の実践事例〜
nullnull
3
380
2026.06.13_AI時代に事業会社が「SIer出身エンジニア」を求める理由 / Why Businesses Seek Engineers with a System Integrator Background in the AI Era
jumtech
0
1k
AI駆動開発が変える、大規模開発の前提 ーHuman in the Loop から Human on the Loop へ / AIE2026
visional_engineering_and_design
30
24k
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
225
10k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
580
The browser strikes back
jonoalderson
0
1.2k
Designing for Performance
lara
611
70k
Navigating Weather and Climate Data
rabernat
0
220
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
200
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2k
How to Talk to Developers About Accessibility
jct
2
230
Navigating Team Friction
lara
192
16k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
160
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