HCIとOpenStackを用いたプライベートクラウド基盤

Transcript

1. 1.

   HCIとOpenStackを⽤いた プライベートクラウド基盤 NTT東⽇本 松村 崇志

2. 2.

   ⾃⼰紹介 1 ü 名前︓松村 崇志 ü 所属︓NTT東⽇本 NW事業推進本部 ⾼度化推進部 運⽤推進部⾨（2016.7-）

   ü 業務︓クラウド（IaaS）技術を活かしたプライベートクラウド基盤の推進 ü 検証⽤クラウド基盤の⽅式検討〜構築〜運⽤〜ゲストサポートまでトータルコーディネイト ü 施策当初から参画（⽣まれて初めてサーバに触れる）したが,ついていけず⼀度リタイアする（後述）
3. 3.

   本⽇のテーマ 2 ü検証⽤プライベートクラウド基盤（HCIとOpenStack）を構築・運⽤ ü なぜOpenStackを選択したか ü なぜHCIを組み合わせたか︖ ü アーキテクチャはどうなっているか︖ ü

   運⽤していてよかったこと、課題に思ったこと
4. 4.

   ü なぜOpenStackを選択したか︖

5. 5.

   その前に、登場⼈物 4 ü 部内は、各部⾨で各プロジェクトが存在 ü 基盤チームはサーバ経験が⻑い先輩（今は上司）当時ド素⼈な私 ◦◦部⾨ プロジェクトA プロジェクトAʼ ・・・

   △△部⾨ プロジェクトB プロジェクトBʼ ・・・ ××部⾨ プロジェクトC プロジェクトCʼ ・・・ ⾃部⾨ 基盤チーム めちゃくちゃ 詳しい先輩 素⼈な私
6. 6.

   検証環境の課題・解決策 5 ü 部内のプロジェクトが個別に検証設備を調達。コストとスピードに課題 ü プライベートなクラウド基盤による解決がミッション APL テナントA テナントB MW

   OS APL MW OS APL MW OS テナントC コストが⾼い （同じ物品を繰り返し購⼊） APL MW OS APL MW OS APL MW OS プライベートクラウド基盤 環境を統合・共⽤する基盤による解決 （増設などの作業はソフトで制御） ◦◦部⾨ プロジェクトA △△部⾨ プロジェクトB ××部⾨ プロジェクトC 調達に時間がかかる （都度ハード調達、 トライアンドエラーのしにくさ） テナントA テナントB テナントC
7. 7.

   「仮想化基盤を作るため」の選択肢 6 ü 数ある技術の中から、まずはOpenStackを採⽤ 出典︓Cloud Native Computing Foundation（CNCF） https://github.com/cncf/landscape

8. 8.

   再構築も⾃由に実施可能 なぜOpenStackか︖ 7 ü 単純なサーバ仮想化にくらべ、ゲストがセルフでテナント構築できる（AWSライクを提供） ü インフラ担当とのやり取り削減（構築期間の短縮） ü ちょっとしたときに作ってちょっとしたときに壊せる（トライ&エラーのやりやすさ） ※ハイパーバイザや各ベンダ技術独⾃のマルチテナント機能を否定するものではありません

   APL 構築 OS 構築 設計 テナント担当 インフラ担当 申 請 ヒアリングシート ・テナントユーザ作成 ・NW設定 仮想 インフラ 構築 設計書 ＜導⼊前＞ ・仮想ストレージ ・仮想NW ・仮想サーバ MW 構築 要件定義 確認 設計 申 請 仮想 インフラ 構築 ＜導⼊後＞ APL 構築 OS 構築 MW 構築 申請後ゲストがすぐに 構築を開始可能 再 依 頼 仮想 インフラ 構築 OS 構築 MW 構築 OS 構築 MW 構築 ・・・ ・・・ テナント担当 インフラ担当
9. 9.

   OpenStack なし OpenStack あり 単純な仮想化でOpenStackライクなことをしようとすると 8 ü インフラ/テナントの権限の境⽬がなくなり、誤操作などによるリスクが発⽣ ü 適切な権限をインフラ/テナント担当者に振ることが⼤事

   ハイパーバイザ テナントA テナントB OpenStack API ハイパーバイザ VM (テナントA) OpenStack コンポーネント テナントA 担当 HW VM (テナントA) VM (テナントB) VM (テナントB) テナントA 担当 HW VM VM × インフラ 担当 テナント インフラ テナント インフラ インフラ 担当 VM VM ▪テナント担当者にインフラ環境の操作権限を付与し、 インフラ側から操作 することになるため、リスクが発⽣ ▪ゲスト管理機能によりあらかじめ割り当てられた領域内で環境を 構築するため、リスクなくテナント構築が可能 ×インフラ環境側から操作するため、他テナントの 環境を閲覧・操作可能。他テナントの環境を 誤って変更/削除してしまう可能性がある。 ×テナント担当もインフラ環境を操作するため、テナン ト単位のリソース状況を正しく管理不可。新規ユーザ にリソースが払い出せないなど適切な運⽤ができない ◦テナント側か ら、テナントAに 閉じた環境を 操作 ◦テナント単位に環境を割り当てているため、テナ ントごとのリソース使⽤状況を正しく管理できる ◦テナントA担当者 はアクセス不可 ※ハイパーバイザや各ベンダ技術独⾃のマルチテナント機能を否定するものではありません
10. 10.

    ü なぜHCIを選択したか︖

11. 11.

    実際にOpenStackでIaaS基盤を検討開始 10 ü 当初、インフラ構成は3Tier構成（ラックマウント/ストレージSW/ストレージ）を採⽤ CT-1 CT-2 CP-1 CT CT CP-N

    … Pacemaker (Act-Stby) VM UT-1 UT-2 Pacemaker (Act-Stby) Zabbix Syslog デプロイ関連 Zabbix Syslog デプロイ関連 BE BE ST ST … VM CP NW VM … VM CP NW CT BE ST CP NW keystone, nova, cinder, horizon, neutron-server, heat RabbitMQ, MySQL glance, cinder-volume nova-compute, neutron-agent neutron-agent (,openvswitch) ・Controllerノード2台(Act-Sby) ・Computeノード4台(Act-Act) ・Utilityノード2台(Act-Sby) 当時のOpenStack構成 お、おう、、、︖ はい、こういう構成ね
12. 12.

    出来上がったものをみると 11 ü とにかくインフラの管理が複雑・⼤変。先輩任せの結果、何が起きているかもわからない事態に。 ü ストレージ設計がわけわからない（＝サーバ設計の敷居の⾼さ） ü OpenStackの複雑さ（=OpenStackの敷居の⾼さ） 検証NW DC-GW#1

    DC-GW#2 DC-SW#1 DC-SW#2 C/Mプレーン L2SW#1 C/Mプレーン L2SW#2 Controller Node 1Act-1Stby iSCSI接続SW#1 iSCSI接続SW#2 共有ストレージ Utilityサーバ 1Act-1Stby 保守NW VPN接続ルータ インターネット接続NW ターミナルサーバ (コンソール接続は省略) インターネット ストレージ セグメント 保守・制御⽤ セグメント VPN接続 ルータ Ctrl Ctrl FC FC NAS コントローラ#1 NAS コントローラ#2 インターネット接続SW#1 インターネット接続SW#2 ユーザセグメント Compute Node 4Act ストレージ増設って配線 だけじゃだめなのか・・・ OpenStackの情 報が全然ない・・・
13. 13.

    ちなみに当時の物理構成図 12 外部NW接続SW#1 （WS-C3850-24T-E） 7 〜 22 1 2 3

    4 5 6 23 24 外部NW接続SW#2 （WS-C3850-24T-E） 7 〜 22 1 2 3 4 5 6 23 24 UプレーンL2SW#1 （WS-C3650-48TS-S） 13 〜 48 Stack Stack 1 2 3 4 5 6 7 8 9 10 11 12 UプレーンL2SW#2 （WS-C3650-48TS-S） 13 〜 48 Stack Stack 1 2 3 4 5 6 7 8 9 10 11 12 Utility#1 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Utility#2 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Compute#3 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Compute#4 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Compute#1 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Compute#2 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Controller#2 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 Controller#1 iLO 1 増1-1 2 増1-2 3 増2-1 4 増2-2 3PAR StoreServ 8200 Node 0 Mng 10G-1 FC1 FC2 10G-2 Node 1 Mng 10G-1 FC1 FC2 10G-2 3PAR StoreServ サービスプロセッサ Mng 3PAR StoreServ File Controller Node 1 iLO L-2 FL-2 Node 3iLO 10G-1 10G-2 FC1 FC2 FC1 FC2 10G-1 10G-2 L-1 FL-1 L-2 FL-2 L-1 FL-1 iSCSI接続SW#1（Aruba 2920 24G Switch） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 A1 A2 B1 B2 StackStack iSCSI接続SW#2（Aruba 2920 24G Switch） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 A1 A2 B1 B2 StackStack C/MプレーンL2SW#1（WS-C3650-48TS-S） 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Stack Stack 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 C/MプレーンL2SW#2（WS-C3650-48TS-S） 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 Stack Stack 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ターミナルサーバ (NS-2250-16) Mng VPN接続ルータ #1 1 2 0 3 4 5 6 7 8 9 検証NW ・・・ ※あまりについていけず ⼀度チームを⾃然離脱。別業 務（NW系）を担当し始める
14. 14.

    そんな中、隣のチームがHCIを検討 13 ü サーバ・FC-SW・ストレージを⼀筐体に収めたインフラアーキテクチャ 出典︓OpenStack Day 2017 https://openstackdays.com/archive/2017/wp-content/uploads/2017/08/5-A2-2.pdf ふむふむ・・・ 先輩がいなくなり

    再び呼ばれた私
15. 15.

    HCI（Nutanix）基本アーキテクチャ 14 出典︓OpenStack Day 2017 https://openstackdays.com/archive/2017/wp-content/uploads/2017/08/5-A2-2.pdf ü 複数の筐体（ノード）をつなげて⼀つのクラスタにする

16. 16.

    なぜHCIを採⽤したか︖ 15 ü インフラがシンプルになる（サーバ設計への敷居を下げてくれる） ü インフラに対しOpenStackが外付けになる（OpenStackへの敷居を下げてくれる） Cluster 3PAR ストレージ OpenStack

    API KVM インフラ テナント NW 機器 OpenStack 多数コンポーネント OpenStack ・Nova Compute ・Neutron-* テナント 3PAR driver ▪3Tier 概念図︓OpenStackを被せて使⽤ ラックマウントサーバ Compute Node インフラ テナント HCI HCI HCI HCI AHV AHV AHV AHV テナント OpenStack 利⽤者 API ▪HCI概念図︓OpenStackを外付けして使⽤ OpenStack ・多数コンポーネント 利⽤者 Nutanix製 Acropolis OpenStack Driver インフラの全NodeにOpenStackコ ンポーネントを⼊れる →バージョンアップの困難さなど、 OpenStackの負の側⾯と正⾯から 向き合う必要が⽣じる インフラにOpenStack要素を⼊れず、外 付けして独⽴ →OpenStackのバージョンアップをインフ ラに影響なく実施可能、OpenStack故 障時の影響もテナント構築に閉じる (=ユーザ通信には影響しない) OpenStack⇔Nutanix間の APIコールを変換してくれる翻訳機 ラックマウントサーバ Controller Node NW 機器 $openstack server create XX $vm.create XX
17. 17.

    導⼊後の構成図 16 ü HCIを10G-SWで束ねたシンプル構成 ü NWも各セグメントを物理的に重畳 OpenStack Controller VM テナントVM

    GitLab VM HCI HCI コアルータ#1 コアルータ#2 HCI集約10G SW#1 HCI集約10G SW #2 HCI 外部接続SW #1 IPMI SW 外部接続SW #1 OpenStack ControllerはHCI上に仮 想サーバとして設置 （その他インフラ機能部も集約） ユーザセグメント ストレージセグメント 保守制御セグメント HCI + 増設するときはどんどん10G-SWに 横つなぎにしていく
18. 18.

    最終的には 17 ü 部内の検証環境プライベートクラウド基盤としてリリース ü 2019/7⽉現在、20テナント/200VM程度搭載 ü 機能追加でGPU対応を実装、コンテナ対応も検討中 インターネット プロダクトA

    検証NW プロダクトB 検証NW プロダクトC 検証NW プロダクトD テナント プロダクトC テナント プロダクトB テナント プロダクトA テナント 共⽤NW インフラ (サーバ仮想化基盤) テナント (仮想システム) NW機器 基盤チームでDevOps的に運⽤ 外部公開NWと接続 必要な時にすぐにトライアル FW マルチテナント 利⽤者毎に独⽴した環境 GPU搭載 AI/機械学習の検証⽤ 独⽴したNW 既存NWに⼿を加える ことなく利⽤可能 HCI HCI HCI HCI HCI GPU VM VM VM VM VM VM VM VM 詳しくなった私
19. 19.

    アーキテクチャを掘り下げる

20. 20.

    OpenStack プロセス 19 ü Controllerからは、Nutanix クラスタが1つのnova computeとして⾒える ü Nutanix上クラスタ上でのVM配置はAcropolisが決定 19

    Nutanix （が担うOpenStack相当の機能） Neutron neutron-server l3-agent Nova nova-compute Cinder cinder-api cinder-scheduler cinder-backup cinder-volume Glance glance-registry glance-api openvswitch-agent dhcp-agent metadata-agent keepalived Controller x2 Nova nova-api nova-scheduler nova-conductor nova-consoleauth nova-novncproxy Octavia octavia-api octavia-worker health-manager housekeeping Heat heat-api heat-api-cfn heat-engine その他 mysql rabbitmq-server Keystone Horizon apache2 corosync pacemaker Cluster インフラ テナント HCI HCI HCI HCI AHV AHV AHV AHV テナント OpenStack 利⽤者 API OpenStack ・多数コンポーネント Nutanix製 Acropolis OpenStack Driver NW 機器
21. 21.

    操作⽅法 20 ü テナント担当はHorizon、インフラ管理者はHorizon + Prismを操作 ü OpenStack ControllerはPrism上から構築する 20

    Cluster HCI AHV HCI AHV HCI AHV HCI AHV プロジェクトB テナント プロジェクトA テナント VM VM VM VM OpenStack インフラ管理 OpenStack Controller Nutanix API ・・・ OpenStack API （ex:Horizon） 利⽤者 Nutanix API （ex:Prism） インフラ管理者 OpenStackのみ操作させる OpenStack controller本 体などはNutanixから操作
22. 22.

    インフラ管理 NW NW 21 ü Provider Network（NW機器でインフラ側で管理） ü 社内の気のしれたユーザが使う、という前提もあり、NWは⼿慣れた物理機器で制御する構想 ü

    プロジェクト/インフラ管理部分でVRFを切り、必要に応じてVRF間ルーティング ü プロジェクト間でIPアドレスがかぶっても⼤丈夫なようにVRF-NATも実装 インフラ担当 NW プロジェクトA NW プロジェクトB NW OpenStack Controller インターネット 仮想ルータ VRF 仮想ルータ VRF 仮想ルータ VRF Nutanix API ︓NAT inside OpenStackから⾒たエンドポイント （実態はPrism ElementやNutanix ABS ターゲットIP、CVM） テナントNW→インフラ管理 向け/インターネット向けは VRF間ルーティング プロジェクトB テナント プロジェクトA テナント VM VM VM VM
23. 23.

    運⽤していてよかったこと、課題に思ったこと （⼀問⼀答形式）

24. 24.

    Q.Compute Nodeが⼀つに⾒えるインパクト（利点） 23 ü リソース（CPU/メモリ/ストレージ）追加でOpenStackを意識しなくて良い ü HCIの増設作業ができる⼈、つまり誰でも実施可能 Cluster OpenStack プロジェクトB

    テナント プロジェクトA テナント HCI VM VM VM HCI HCI VM AHV AHV AHV OpenStackからは常に1つのCompute Nodeでしかない →配線+数クリックだけで増設が可能。 OpenStackに触らなくてよい HCI AHV +
25. 25.

    Q.Compute Nodeが⼀つに⾒えるインパクト（課題） 24 ü インフラ担当でHCIのノード単位を意識する作業が度々ある ü ノード単位のアフィニティ設定（CPノードが1つに⾒える性質上不可避） →OpenStackで構築後、Prism上から設定することで解決（インフラ担当の介在） ü 1ノードのスペックを意識したテナントリソースの配置

    →テナント搭載時のサイジングの際に、Nutanixを意識する必要あり 残リソース 10 コア 残リソース 10 コア VM （15コア） Cluster OpenStack プロジェクトA テナント HCI VM VM HCI HCI AHV AHV AHV 残リソース 10 コア 合計30 コア （クラスタとしては） + + = VM VM OpenStackからはノードを 指定して配置できない →Prismから指定する （VM-VM antiaffinity、 VM-Host affinity） OpenStackからは空いて いるように⾒えるが、 Nutanix上は空いていない ︖
26. 26.

    Q.OpenStackを使わないマルチテナント︖⽅法1 25 A.テナントごとにクラスタを作る（1テナント:1クラスタ、クラスタ専有） ü ハイパーバイザなど独⽴した環境が作成、ノイジーネイバーの解消 ü 実質サイロ（なんちゃって仮想化） →集約効果が⾒込めない、クラスタを専有して使うニーズもなかったため、不採⽤ （将来的にニーズがあれば、クラスタ専有型+クラスタ共有型のハイブリッド化なども検討） Cluster

    HCI HCI HCI AHV Cluster HCI HCI HCI Cluster HCI HCI HCI VMWare Hyper-V ◦◦部⾨ プロジェクトA △△部⾨ プロジェクトB ××部⾨ プロジェクトC プロジェクトC テナント プロジェクトB テナント プロジェクトA テナント VM VM VM VM VM VM
27. 27.

    Q.OpenStackを使わないマルチテナント︖⽅法2 26 A. Self Service Portal（SSP）を利⽤ ü Nutanix社 が提供するプライベートクラウドライクなポータル機能 →Heat/OctaviaなどOpenStack独⾃機能の需要も⾼かったため不採⽤

    出典元︓https://qiita.com/hanakara_milk/items/4491c26a58402135868f
28. 28.

    Q.バージョン追従する⼤変さ 27 ü ①・②・③を絶妙に合わせていく必要あり ü 3Tier構成で悩まされているストレージ ドライバなどは意識しなくてよくなる インフラ管理 インフラ (サーバ仮想化基盤)

    ③Nutanixソフトウェア（AOS5.5→AOS5.10） OpenStack Controller ②Nutanixプラグイン （Newton⽤→ Queens⽤） テナント (仮想システム) Ubuntu OS ①OpenStackソフトウェア （Newton→Queens） 互換性 互換性 プロジェクトB テナント プロジェクトA テナント VM VM VM VM Cluster HCI HCI HCI バージョンアップ イメージ図（実際に計画中） ControllerのOSも考慮 の必要あり
29. 29.

    2019年度 2020年度 2021年度 1Q 2Q 3Q 4Q 1Q 2Q 3Q

    4Q 1Q 2Q 3Q 4Q コントロールノード ① OpenStack ソフトウェア ②Nutanix プラグイン ③Nutanix OS （AOS） バージョンアップ 検証作業 5.10 LTS 6.X LTX 6.Y LTS Stein Train Uxxx Rocky Rocky版プラグイン Train版プラグイン Stein版プラグイン Uxxx版プラグイン ①②③をバージョンアップ 実施（∵①②新機能） ③のみバージョンアップ実 施（∵③EoL） パッチ無し ①②③をバージョンアップ 実施（∵③EoL＋①② 新機能） 検証 検証 検証 Queens Queens版プラグイン Q.バージョン追従する⼤変さ 28 A. 定期的に実施 ※1 本資料で掲載されたスケジュールはNutanix社の今後の正確なロードマップを⽰すものではありません
30. 30.

    Q.リソースのオーバーコミットはしているか 29 A. CPUはオーバーコミットあり、メモリ/HDDはオーバーコミットなし ü Nutanix HCIの仕様に準拠 ü （余談）メモリが不⾜しがちな傾向 ü

    ⼀度メモリ単体で増設を実施。コスト的にもノード増設（≒CPU/メモリ/HDDの⼀⻫増設）より安く済む オーバーコミット オーバーコミット時の影響 ※（⼀般論） CPU あり 中 負荷が下がるまでパフォーマンスに影響があるが 短時間で現状復帰 メモリ なし ⼤ スワップのため、パフォーマンス低下が暫く続く ストレージ ⼤ ストレージ上のVMが停⽌の恐れあり オーバーコミットのありなし、オーバーコミット時の影響
31. 31.

    Q.ドライバーの形態について 30 ü OpenStackドライバの利⽤形態は3つの⽅式 ü 当初はOpenStackのControllerは別の物理媒体に切り出し（スタンドアローンOVM構成） ü さらなるシンプル化のため、後々ドライバモードへ（今の構成） ドライバモード（OVM-less）構成 スタンドアローンOVM構成

    オールインワン構成 OpenStack Controller Acropollis OpenStack ドライバ Nutanix AHV クラスタ OpenStack Controller OVM Acropollis OpenStack ドライバ Nutanix AHV クラスタ OVM OpenStack Controller + Acropollis OpenStack ドライバ Nutanix AHV クラスタ
32. 32.

    Q.どうやってエンジニアを育てるか 31 ü Nutanix + OpenStackに詳しいエンジニアが（少なくとも3Tierに⽐べると）多くはない ü どちらかを知っていれば、話は早いが、、 =====個⼈的な所感===== ü

    初⼼者ならNutanixから学ばせる⽅針 （エンジニア初⼼者にとっても、サーバ分野への参⼊の敷居を下げてくれる） ü Nutanix バイブル ü Nutanix 資格 ü Nutanix Community Edition etc 無料で座学・実機で学べるものも多い ü OpenStackもオープンだが、いかんせん今でも情報が少なく、若⼲壁が⾼いように感じる üググっても出てくる情報は⼤体Libertyとか・・・
33. 33.

    今後の取り組み・機能追加

34. 34.

    Cluster GPU 対応 33 ü クラスタのうち、⼀部ノードはGPU（Tesla V100 ×2）を搭載 ü vGPU+仮想マシン単位でプロダクトへ払い出し

    ü 現在はOpenStackとintegrateされていないため、インフラ担当で仮想マシンを作成して引き渡す プロジェクトC テナント プロジェクトB テナント プロジェクトA テナント HCI VM VM VM VM HCI HCI HCI OpenStack ・・・ GPU vGPU vGPU GPU vGPU vGPU ・・・ ・・・ VM VM VM プロジェクトC GPU付きVM AHV AHV AHV AHV プロジェクトD GPU付きVM GPUがOpenStack管理下ではないため Prismからインフラ担当で作成
35. 35.

    コンテナ 対応 34 ü Nutanix社のマネージドk8s「Nutanix Karbon」を実装予定 ü CNCFのCertified k8s Hostedとして登録

    ü 現時点でコンテナを利⽤したいユーザは、各⾃Dockerなどをコンテナにインストールしてもらう 出典元︓https://www.cncf.io/certification/software-conformance/
36. 36.

    まとめ 35 ü検証⽤プライベートクラウド基盤（HCIとOpenStack）を構築・運⽤ ü なぜOpenStackを選択したか テナントがセルフでテナント構築ができるから。 インフラ管理者とのやり取りが減る（構築期間の短縮、PoCのやりやすさ）から ü なぜHCIを組み合わせたか︖ HCIがサーバ/OpenStackへの敷居を下げてくれるから

    （インフラがシンプルになる、インフラに対しOpenStackが外付けになる） ü アーキテクチャはどうなっているか︖ Nutanix DriverがOpenStack語とNutanix語を翻訳してくれる ü 運⽤していて感じたこと Compute-Nodeが1つに⾒えることによるインパクトの⼤きさ バージョンアップへの追従
37. 37.

    36 ご清聴ありがとうございました 管理番号︓K19-01119 使⽤期間︓2019/7/22-2034/7/22