JJUG CCC 2025 Fall バッチ性能!!劇的ビフォーアフター

バッチ性能!! 劇的ビフォーアフター JJUG CCC 2025 Fall 2025/11/15 株式会社野村総合研究所生産革新センター林優一郎
/ 鈴木彩香

1 Copyright （C） Nomura Research Institute, Ltd. All rights reserved.
バッチアプリケーションの性能 02 性能検証モデル 03 性能検証結果 04 01 野村総合研究所とxPaletteについてイベントのお知らせ 05

野村総合研究所とxPaletteについて 01

野村総合研究所野村総合研究所とxPaletteについて 1965年創業、今年で創業60周年を迎えました。 NRIでは4つの事業を通して、社会の仕組みづくり、顧客のビジネス、人々の快適な暮らしを支えています。マネジメントとシステム分野においてあらゆる産業のコンサルティングコンサルティング産業分野でのシステム開発やソリューションを提供産業ITソリューション企業のIT基盤の構想・設計・構築・運用などのサービスやソリューションを提供 IT基盤サービス金融分野でのシステム開発やソリューションを提供金融ITソリューション

生産革新センター野村総合研究所について主な事業内容生産革新センターはテクニカル領域に特化した組織です。アプリケーション開発の生産性向上のためのソリューション提供、お客様のDXの実現を支援するサービスの提供を行っています。フレームワークの開発や技術支援独自フレームワークの開発や最新技術の検証、実開発案件への技術支援などを行っております。 AIを活用した新たな開発手法確立フレームワーク開発や技術支援で得られたノウハウを基に、AIを利用した開発プロセスや開発手法を確立しソフトウェア開発現場における開発スタイルの変革を目標として活動しています。顧客業務のAI活用支援画像解析や音声認識などの技術を背景に、お客様の業務改革を目的とした業務特化型のAI開発や、最新技術動向の調査やR&Dなどを行っています。

開発コミュニティ活動(xPalette) 野村総合研究所について xPalette(クロスパレット)とは？

xPaletteが提供するモノ開発コミュニティ活動ガイドラインライブラリサンプル/テンプレート Prj 開発手順や方式の説明開発に利用可能な部品群開発の雛形/実装例各処理方式についての設計考慮事項を記載。設計ガイドラインの内容に沿ってアプリケーションを実装する際の実装方式や実装例を参照することで高品質なアプリケーション開発が可能となる。ガイドラインに記載した部品をライブラリとして提供。テンプレートプロジェクトに組み込むことで素早いアプリケーション開発が可能となる。ガイドラインに記載した実装例を実際に動くサンプルコードとして提供。テンプレートは開発開始時にプロジェクトの雛形として利用する。

開発コミュニティ活動(xPalette)の構想開発コミュニティ活動 (開発ベースライン) フィードバック社外のエンジニア/企業 NRIのお客様開発/エンハンス xPalette開発コミュニティ社内開発PJ 公開/利用プロダクト開発公開/利用フィードバック構想

xPaletteの活動領域開発コミュニティ活動バックエンド領域アプリ実行基盤領域フロントエンド領域アプリケーションレイヤーインフラレイヤー APP

バックエンド領域の活動開発コミュニティ活動バッチアプリケーションオンラインアプリケーション非同期アプリケーションバックエンド領域では「バッチ」「オンライン」「非同期」の3軸で活動中特定の時刻やイベントで起動し、特定の処理を実行するアプリケーションクライアントからのリクエストに応じた処理を実行し、即時に処理結果を応答するアプリケーション処理要求に対して、処理結果を即時に応答せず、別のサーバーで処理を実行するアプリケーション

バックエンド領域の活動開発コミュニティ活動バッチアプリケーションオンラインアプリケーション非同期アプリケーションバックエンド領域では「バッチ」「オンライン」「非同期」の3軸で活動中特定の時刻やイベントで起動し、特定の処理を実行するアプリケーションクライアントからのリクエストに応じた処理を実行し、即時に処理結果を応答するアプリケーション処理要求に対して、処理結果を即時に応答せず、別のサーバーで処理を実行するアプリケーション本日は JJUG CCC 2024 Fall の続きとして、バッチアプリケーション向けの取り組み事例について話します

バッチアプリケーションの性能 02

バッチアプリケーションにおける重要な設計観点バッチアプリケーションの性能バッチアプリケーションで重要な設計観点は下記の2点です性能効率性バッチアプリケーションにおける目的の1つは大量のデータを処理することです。そのため、処理対象のデータ量を想定時間内に処理しきる必要があります。信頼性大量のデータ処理中に異常が発生した場合、データの整合性が崩れる可能性があります。そのため、異常発生におけるデータ整合性を保つための仕組みやリカバリ運用の単純化といった考慮が必要となります。本日は「性能効率性」をメインテーマとしてお話します！！

バッチアプリケーションの性能に関わる主な設計ポイントバッチアプリケーションの性能設計ポイントはわかったが、どのポイントをどれだけいじれば性能が変わるのか？具体的な性能差が知りたいが・・・ログ出力量大量のログを出力する場合、ログ出力のIOが多発するため処理性能が低下する。設計ポイント① コミット方式データベースやファイルへのデータ出力(コミット処理)単位を変更することで処理性能が変化する。設計ポイント② ジョブの多重化ジョブの処理を多重化することで、大量のデータを効率的に処理することができるため処理性能が向上する。設計ポイント③

バッチアプリケーションの性能に関わる主な設計ポイントバッチアプリケーションの性能実際のジョブに対して各設計ポイントの設定を変更して処理時間を計測し、設計ポイントごとの性能ベンチマークを測定しました！！ログ出力量大量のログを出力する場合、ログ出力のIOが多発するため処理性能が低下する。設計ポイント① コミット方式データベースやファイルへのデータ出力(コミット処理)単位を変更することで処理性能が変化する。設計ポイント② ジョブの多重化ジョブの処理を多重化することで、大量のデータを効率的に処理することができるため処理性能が向上する。設計ポイント③

性能検証モデル 03

性能検証の背景と目的性能検証大量のデータを扱うバッチアプリケーションにおいて、コミット方法などの処理方式の差が性能にどの程度影響するのか指標がなかった性能検証の背景実案件相当のデータベースとバッチジョブを用いて性能検証を行います。データバッチ実際に測定をして、バッチアプリケーション開発における性能チューニングの指標として利用！性能検証の目的

データ – TPCモデル性能検証モデルデータベースのトランザクション性能検証を目的に作成されたベンチマーク TPC-C 小売業の注文処理及び在庫管理シナリオを模倣。 TPC-H 製造業や流通業などの一般的なビジネスシナリオを模倣。 TPC-E 証券口座の管理、株式の取引、投資家のアクティビティを模倣。 TPC-DS 小売業などのさまざまな業界のビジネス分析シナリオを模倣。 Oracle DatabaseやMicrosoft SQL Server、IBM Db2などにおいて、処理能力（スループット）、応答速度、スケーラビリティの測定に使用されてます。

TPC-Hモデル性能検証モデル ※スケールファクタによりデータ量を任意に調整可能テーブル名概要データ量(件) CUSTOMER 顧客情報 150万 ORDERS 受注情報 1,500万 LINEITEM 注文の明細情報 6,000万 PART 製品情報 200万 SUPPLIER 供給者情報 10万 PARTSUPP 製品と供給者の関係情報 800万 NATION 国情報 25 REGION 地域情報 5 製造業や流通業、その他一般的なビジネスシナリオを模倣したベンチマーク

顧客注文金額集計ジョブ性能検証モデル指定された年月における顧客ごとの注文金額を集計し、注文金額集計テーブルに登録するジョブ出力テーブル入力テーブル UPDATE 顧客あたりn件顧客注文金額集計ジョブ INSERT 顧客あたり1件

ジョブフロー性能検証モデル CUSTOMER ① 顧客情報取得 ② 注文情報取得ジョブ開始パラメータ取得 ③ 注文金額算出 ④ ステータス更新 ⑤ テーブル登録ジョブ終了 ORDERS ORDERS ORDER_PRICE_SUMMARY 金額を算出したデータのステータスを集計済みに更新集計結果をテーブルに登録全顧客分繰り返しすべての顧客情報を取得顧客ごとの注文情報を取得

実行環境性能検証モデル ※バッチ実装方法の詳細はこちらをご参考下さい。ボリュームタイプインスタンスタイプ t3.medium マグネティック JJUG CCC 2024 Fallの資料バッチサーバデータベースサーバログ保存 TPC-Hを構築バッチはSpring Bootをベースとしたフレームワークを採用し、データベースはMySQLを使用

設計ポイントごとのベンチマーク測定性能検証モデル同一ジョブに対して設計ポイントごとに実行時間を比較ログ出力量ログ出力の有無で性能を比較 • ログ出力あり • ログ出力なし設計ポイント① コミット方式コミット方式/コミット間隔の違いによる性能を比較 • 逐次コミット • 一括コミット • 中間コミット設計ポイント② ジョブの多重化ジョブを多重化した場合の性能を比較 • 多重化あり • 多重化なし設計ポイント③

性能検証結果 04

ベンチマーク測定：ログ出力量性能検証結果顧客注文金額集計ジョブに対して、ログ出力ありの場合とログ出力なしの場合の処理時間を比較ログ出力量ログ出力の有無で性能を比較 • ログ出力あり • ログ出力なし設計ポイント① コミット方式コミット方式/コミット間隔の違いによる性能を比較 • 逐次コミット • 一括コミット • 中間コミット設計ポイント② ジョブの多重化ジョブを多重化した場合の性能を比較 • 多重化あり • 多重化なし設計ポイント③

ログ出力量性能検証結果ログ出力ありログ出力なしログレベル：INFO ログバイト数：1,178バイトログレベル：INFO,DEBUG ログバイト数：4,393,713,140バイト ①顧客情報取得 ②注文情報取得ジョブ開始パラメータ取得 ③注文金額算出 ④ステータス更新 ⑤テーブル登録ジョブ終了ログ出力ありログ出力なし全顧客分繰り返し 2025/09/26 01:48:47 INFO [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20250926-014842] j.c.n.x.e.b.j.o.OrderPriceSummaryOnceCommitJob - === 顧客注文金額集計ジョブ（一括コミット）開始 === 対象年月:1995年5月 2025/09/26 02:32:19 INFO [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20250926-014842] j.c.n.x.e.b.j.o.OrderPriceSummaryOnceCommitJob - === 顧客注文金額集計ジョブ（一括コミット）正常終了 === 対象年月: 1995年5月 2025/09/26 02:32:19 INFO [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20250926-014842] j.c.n.x.example.batch.common.runner.JobRunner - job finished, total execution time 2612.876627073s, result=SUCCESS, exit-code=0. 2025/10/02 05:20:51 INFO [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20251002-052046] j.c.n.x.e.b.j.o.OrderPriceSummaryOnceCommitJob - === 顧客注文金額集計ジョブ（一括コミット）開始 === 対象年月:1995年5月 2025/10/02 05:20:51 DEBUG [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20251002-052046] j.c.n.x.e.b.j.o.OrderPriceSummaryOnceCommitJob - 顧客情報の取得開始 2025/10/02 05:20:51 DEBUG [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20251002-052046] j.c.n.x.e.b.j.m.C.selectAllCustomers - ==> Preparing: SELECT C_CUSTKEY, C_NAME, C_ADDRESS, C_NATIONKEY, C_PHONE, C_ACCTBAL, C_MKTSEGMENT, C_COMMENT FROM CUSTOMER ORDER BY C_CUSTKEY 2025/10/02 05:20:51 DEBUG [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20251002-052046] j.c.n.x.e.b.j.m.C.selectAllCustomers - ==> Parameters: 2025/10/02 05:21:13 DEBUG [vm01] [main] [job:order-price-summary-once-commit] [id:order-price-summary-once-commit-20251002-052046] j.c.n.x.e.b.j.o.OrderPriceSummaryOnceCommitJob - 顧客情報取得: ID=1, 名前=Customer#000000001 …

ログ出力量による処理時間比較性能検証結果 10 20 30 40 50 処理時間 (分) ログありログなし 50分37秒 47分13秒 ※一括コミット方式を採用

ログ出力量による処理時間比較性能検証結果 10 20 30 40 50 処理時間 (分) ログありログなし 50分37秒 47分13秒 ※一括コミット方式を採用ログ出力をなくすことで約3分ほど時間が短縮

ログ出力のボトルネック性能検証結果大量のログ出力処理による処理性能低下 ① バッチ処理中に大量のログを出力すると、ログの書き込みのI/O処理がボトルネックとなり、全体の処理性能が大幅に低下する可能性があります。特に大規模データを処理する場合ログ出力の有無が処理時間に大きく影響します。ログ出力先のストレージの圧迫 ② 機械的なログ出力により、ストレージ容量が急速に消費されます。これにより、ストレージコストの増加だけでなく、ディスク容量不足によるジョブの異常停止といった深刻な問題が発生する可能性があります。処理時間の増加 I/Oボトルネックスループット低下ストレージコスト増ディスク容量不足ジョブ異常停止

ログ出力の検討性能検証結果 ① 大量のログ出力処理による処理性能低下 ② ログ出力先のストレージの圧迫デメリットメリット ① エラー/障害発生時の調査が容易になる ② 処理状況の把握が可能になるログをどの程度削減するかは業務処理の重要性を考慮して検討することが大切

ベンチマーク測定：コミット方式性能検証結果顧客注文金額集計ジョブに対して、逐次コミット、一括コミット、中間コミットを採用した場合の処理時間を比較ログ出力量ログ出力の有無で性能を比較 • ログ出力あり • ログ出力なし設計ポイント① コミット方式コミット方式/コミット間隔の違いによる性能を比較 • 逐次コミット • 一括コミット • 中間コミット設計ポイント② ジョブの多重化ジョブを多重化した場合の性能を比較 • 多重化あり • 多重化なし設計ポイント③

コミット方式の違い性能検証結果一括コミット顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 全データ(150万件)をまとめてDBに反映業務処理全150万件次のデータを処理ジョブ全体の処理が完了した後、すべてのデータ変更をまとめて一度だけコミットする方式顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 業務処理全150万件次のデータを処理処理の途中に一定単位で区切り、複数回に分けてコミットする方式コミット間隔コミット間隔(n件)ごとにまとめてDBに反映全件処理するまで繰り返し中間コミット顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 業務処理全150万件次のデータを処理 1件ごとDBに反映個々の処理やレコードごとに随時コミットを行う方式逐次コミット

コミット方式の違い性能検証結果一括コミット顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 全データ(150万件)をまとめてDBに反映業務処理全150万件次のデータを処理ジョブ全体の処理が完了した後、すべてのデータ変更をまとめて一度だけコミットする方式顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 業務処理全150万件次のデータを処理処理の途中に一定単位で区切り、複数回に分けてコミットする方式コミット間隔コミット間隔(n件)ごとにまとめてDBに反映全件処理するまで繰り返し中間コミット顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 業務処理全150万件次のデータを処理 1件ごとDBに反映個々の処理やレコードごとに随時コミットを行う方式逐次コミットコミット回数：150万回コミット回数：1回コミット回数：150万件/n回

コミット単位による処理時間比較性能検証結果 10 20 30 40 処理時間 (分) 逐次コミット (コミット回数：150万回) 7時間41分 50 中間コミット (コミット回数：15回) 37分19秒一括コミット (コミット回数：1回) 47分13秒 ※中間コミットのコミット間隔は10万件

コミット単位による処理時間比較性能検証結果 10 20 30 40 処理時間 (分) 7時間41分 50 37分19秒 47分13秒中間コミットの処理時間が最も短い逐次コミット (コミット回数：150万回) 中間コミット (コミット回数：15回) 一括コミット (コミット回数：1回) ※中間コミットのコミット間隔は10万件

逐次コミット > 一括コミット > 中間コミット処理時間 ※検証では、MybatisのSqlSessionTemplateを使用（コミット＝DBへのデータ転送/書き込み） ⚫ 逐次コミット：コミット処理のオーバヘッドが大きい ⚫ 一括コミット：未コミットログが肥大化するため性能を圧迫 ⚫ 中間コミット：適切な粒度でコミットすることで、DBの未コミットログを肥大化させることなく、逐次コミットのオーバヘッドも低減 (コミット回数：150万回) (コミット回数：1回) (コミット回数：15回) コミット単位による処理時間変動の考察性能検証結果

コミット方式のメリット・デメリット性能検証結果一括コミット中間コミット逐次コミットメリット ⚫コミット済みのデータは永続化されるため、エラーの影響が局所化される ⚫外部システムのデータを更新する処理においてはデータの一貫性を担保しやすいデメリット ⚫データベース書き込みのたびにコミットするため、処理が遅くなるメリット ⚫コミット回数が少なくなるため負荷分散が可能 ⚫コミット済みのデータは永続化されるため、エラーの影響が局所化されるデメリット ⚫リカバリ処理が複雑になる可能性があるメリットデメリット ⚫エラー発生時にすべての処理がロールバックされるためジョブ実行がなかったことにできる ⚫大量件数処理時に高負荷になる可能性がある ⚫エラー発生時のリランでは、処理を最初からやり直すためリカバリ運用に時間がかかる

コミット方式の違い性能検証結果一括コミット顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 全データ(150万件)をまとめてDBに反映業務処理全150万件次のデータを処理ジョブ全体の処理が完了した後、すべてのデータ変更をまとめて一度だけコミットする方式顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 業務処理全150万件次のデータを処理処理の途中に一定単位で区切り、複数回に分けてコミットする方式コミット間隔コミット間隔(n件)ごとにまとめてDBに反映全件処理するまで繰り返し中間コミット顧客情報取得テーブル登録 CUSTOMER 顧客情報取得 ORDER_PRICE _SUMMARY 業務処理全150万件次のデータを処理 1件ごとDBに反映個々の処理やレコードごとに随時コミットを行う方式逐次コミットコミット回数：150万回コミット回数：1回コミット回数：150万/n回コミット間隔(n件)を変化させて検証

コミット数による処理時間比較性能検証結果 10 20 30 40 処理時間 (分) 39分31秒 35分14秒 37分19秒 1,000件 (コミット：1,500回) 10万件 (コミット：15回) 1万件 (コミット：150回) コミット間隔

コミット数による処理時間比較性能検証結果 10 20 30 40 処理時間 (分) 39分31秒 35分14秒 37分19秒 1,000件 (コミット：1,500回) 10万件 (コミット：15回) 1万件 (コミット：150回) コミット間隔コミット数1万のときの処理時間が最も短い

ベンチマーク測定：ジョブの多重化性能検証結果顧客注文金額集計ジョブに対して、多重化ありの場合と多重化なしの場合の処理時間を比較ログ出力量ログ出力の有無で性能を比較 • ログ出力あり • ログ出力なし設計ポイント① コミット方式コミット方式/コミット間隔の違いによる性能を比較 • 逐次コミット • 一括コミット • 中間コミット設計ポイント② ジョブの多重化ジョブを多重化した場合の性能を比較 • 多重化あり • 多重化なし設計ポイント③

ジョブの多重化性能検証モデル入力データを各ファイルに分割し、ファイルごとに同一ジョブを多重実行する方式 1,000,000~1,500,000 500,000~1,000,000 1~500,000 データ分割ジョブ CUSTOMER 顧客注文金額集計ジョブ1 顧客注文金額集計ジョブ2 顧客注文金額集計ジョブ3 CUSTOMER 1~500,000 CUSTOMER 500,000~1,000,000 CUSTOMER 1,000,000~1,500,000 多重度によるデータ分割処理顧客注文金額集計ジョブを多重で実行

多重化による処理時間比較性能検証結果 10 20 30 40 処理時間 (分) 多重なし多重あり 35分14秒 18分9秒 ※中間コミット（コミット件数1万）、多重度3

多重化による処理時間比較性能検証結果 10 20 30 40 処理時間 (分) 多重なし多重あり 35分14秒 18分9秒 ※中間コミット（コミット件数1万）、多重度3 多重化することで処理時間が約半分に短縮

47分13秒まとめ性能検証結果 10 20 30 40 50 処理時間 (分) 逐次コミットログなし一括コミットログあり 7時間41分 35分14秒 18分9秒 50分37秒 3分24秒 11分59秒 17分5秒一括コミットログなし中間コミットログなし中間コミットログなし多重化 32分28秒 ※中間コミット（コミット件数1万）、多重度3

47分13秒まとめ性能検証結果 10 20 30 40 50 処理時間 (分) 逐次コミットログなし一括コミットログあり 7時間41分 35分14秒 18分9秒 50分37秒 3分24秒 11分59秒 17分5秒一括コミットログなし中間コミットログなし中間コミットログなし多重化 32分28秒 ※中間コミット（コミット件数1万）、多重度3 設計を工夫することで半分以上の時間を短縮することが可能

47分13秒まとめ性能検証結果 10 20 30 40 50 処理時間 (分) 逐次コミットログなし一括コミットログあり 7時間41分 35分14秒 18分9秒 50分37秒 3分24秒 11分59秒 17分5秒一括コミットログなし中間コミットログなし中間コミットログなし多重化 ※中間コミット（コミット件数1万）、多重度3 32分28秒

47分13秒まとめ性能検証結果 10 20 30 40 50 処理時間 (分) 逐次コミットログなし一括コミットログあり 7時間41分 35分14秒 18分9秒 50分37秒 3分24秒 11分59秒 17分5秒一括コミットログなし中間コミットログなし中間コミットログなし多重化 ※中間コミット（コミット件数1万）、多重度3 32分28秒しかし・・・

さらなる性能向上！性能検証結果実装方式だけで大きく性能を向上させることができるが、さらに性能を上げる方法があります。その方法は・・・

さらなる性能向上！性能検証結果単純明快！お金の力を使います！！

さらなる性能向上！性能検証結果インスタンスタイプ：t3.medium (4GiBメモリ, USD 0.0544/時間) ボリュームタイプ：マグネティック (IOPS 40~200, USD 0.08/GB 月) インスタンスタイプ：r6i.xlarge (32GiBメモリ, USD 0.304/時間) ボリュームタイプ：io2 (IOPS 3000, USD 0.142/GB 月)

マシンスペックを上げた場合性能検証結果 10 20 処理時間 (分) 通常のマシンスペックを上げたマシン 6分3秒 18分9秒 ※ログ出力なし、中間コミット（コミット件数1万）、多重度3 インスタンスタイプ：r6i.xlarge ボリュームタイプ：io2 インスタンスタイプ：t3.medium ボリュームタイプ：マグネティック

マシンスペックを上げた場合性能検証結果 10 20 処理時間 (分) 通常のマシンスペックを上げたマシン 6分3秒 18分9秒 ※ログ出力なし、中間コミット（コミット件数1万）、多重度3 インスタンスタイプ：r6i.xlarge ボリュームタイプ：io2 インスタンスタイプ：t3.medium ボリュームタイプ：マグネティックさらに3分の1まで処理時間が減少

マシンスペックを上げた場合性能検証結果基本的にバッチアプリケーションは大量のデータを入力し出力します。ディスクのIOPSやメモリ、CPUサイズなどを「課金」すればさらなる性能向上を得ることができます！マシンスペックの向上は、ジョブごとに適したマシンを選択することが重要です。 ⚫ 金銭的に余裕がある ⚫ アプリ全体に手が入れづらい ⚫ 急いで性能を上げる必要があるといった場合に用いる手段です。

JJUG CCC 2025 Fall バッチ性能!!劇的ビフォーアフター

JJUG CCC 2025 Fall バッチ性能!!劇的ビフォーアフター

More Decks by HayashiYuichiro

Other Decks in Technology

Featured

Transcript