HAクラスタで PostgreSQLを高可用化 (後編) ～ レプリケーション編 ～

Transcription

1 試して覚える Pacemaker 入門 PG-REX 構築 (Pacemaker+PostgreSQL によるシェアードナッシング構成構築 ) Linux-HA Japan

2 さっそくですが PG-REX とは 2

3 PG-REX とは構成モデルの名称である! PG-REX とは PostgreSQL と Pacemaker と PG-REX 運用補助ツールを組み合わせてシェアードナッシング構成の HA クラスタを実現した構成モデルです SQL 発行 クライアント データ同期 PG-REX 運用 PG-REX 運用補助ツール ノード #1 補助ツールノード #2 保守 運用者 3

4 PostgreSQL の HA クラスタ構成 PostgreSQL の HA クラスタを構築する場合 以下の 2 パターンが考えられます シェアードディスク構成 シェアードナッシング構成 故障 SQL 発行 SQL 発行更新更新 ノード #1 ノード #2 DB データ シェアードディスク 故障 Master 更新ノード #1 ノード #2 DB データ ローカルディスク SQL 発行 SQL 発行 データ同期 Slave Master DB データ 更新 ローカルディスク PG-REX ではこちらの構成を実現します 4

5 セミナー概要 本セミナーでは PG-REX の構築方法を紹介します PG-REX 構成では PostgreSQL や Pacemaker に特殊な設定が必要で シェアードディスク構成より構築が難しくなっているため 本セミナーで分かりやすく説明します シェアードディスク構成の構築方法は以下のセミナー資料で紹介しているため こちらをご参照ください 試して覚える Pacemaker 入門リソース設定編 5

6 PG-REX の概要 PG-REX では PostgreSQL の機能を使用してデータを同期し Pacemaker と PG-REX 運用補助ツールにより自動化しています SQL 発行 クライアント Master アプリケーション自動管理 PG-REX 運用補助ツール 一括制御 データ同期 Slave アプリケーション自動管理 PG-REX 運用補助ツール 一括制御 ノード #1 ノード #2 PG-REX ではこの 3 つが組み合わさりシェアードナッシング構成を実現しています PostgreSQL による データ同期 Pacemaker による アプリケーション自動管理 PG-REX 運用補助ツールによる 一括制御 保守 運用者 6

7 PostgreSQL による データ同期 データ同期は PostgreSQL の同期レプリケーション機能によって実現します SQL 発行 クライアント PostgreSQL は更新されたデータをディスクに永続化する際に WAL ファイルとして書き出します ノード #1 Master WAL 更新 データ同期 WAL Slave ノード #2 WAL 更新 同期レプリケーション機能はこの WAL ファイルを対向ノードへ同期書き込みする機能になります DB データ ローカルディスク DB データ ローカルディスク 7

8 Pacemaker による アプリケーション自動管理 故障発生時に PostgreSQL の Master/Slave 切替 ( フェイルオーバ ) などは Pacemaker によって自動管理します SQL 発行 クライアント SQL 発行 故障 Master 故障監視 Master Slave 故障監視 Master へ昇格 ノード #1 ノード #2 8

9 PG-REX 運用補助ツールによる 一括制御 PG-REX 運用補助ツールとはPG-REX 構成における保守操作を簡易化するスクリプトです Master SQL 発行 一括制御 PG-REX 運用補助ツール クライアント ノード #1 ノード #2 保守 運用者 Slave 一括制御 PG-REX 運用補助ツール PG-REX 運用補助ツールは PG-REX の保守時に必要となる操作を簡易に実行できるようにします PG-REX 起動 PG-REX 停止 Master/Slave 手動系切替 PostgreSQL アーカイブログの整理 Pacemaker と PostgreSQL のコマンドをラッピングし 操作する上で必要となる複数の手順を一括実行できるようにします 9

10 本セミナーの流れ 以降では以下の順で PG-REX 構築手順とその勘所を紹介します PostgreSQL の同期レプリケーション設定方法と PostgreSQL 単体で HA クラスタを組む場合に必要な手順について紹介 Pacemaker PG-REX 運用補助ツール設定方法と導入する事で自動化できることについて紹介 設定 構築方法のみをお求めの場合は以下のサイトで配布されているマニュアルをご参照ください PG-REX プロジェクト 10

11 さっそく PostgreSQL の同期レプリケーション設定 の紹介 11

12 PostgreSQL の同期レプリケーション設定の流れ 1. DB 初期化 $ initdb -D /dbfp/pgdata/data -X /dbfp/pgxlog/pg_xlog --encoding=utf-8 --no-locale --data-checksums 2. レプリケーションユーザ作成 $ psql -c "CREATE ROLE repuser REPLICATION LOGIN PASSWORD 'reppasswd'" 3. レプリケーションユーザのアクセス許可設定 $ vi $PGDATA/pg_hba.conf 4. パスワードファイル設定 $ vi ~/.pgpass 5. 同期レプリケーション設定 $ vi $PGDATA/postgresql.conf PostgreSQL のインストール等は両ノードとも完了し 使用可能であることを前提としています 12

13 1. DB 初期化 各 DB ファイルを格納するディレクトリを作成します [ ノード 1 ノード 2] # mkdir -p /dbfp/pgdata $PGDATA ディレクトリ # mkdir -p /dbfp/pgxlog WAL 格納ディレクトリ ( 同期レプリケーションではこの WAL を転送します ) # mkdir -p /dbfp/pgarch/arc1 アーカイブログディレクトリ # chown -R postgres:postgres /dbfp 以下のコマンドで DB を初期化します [ ノード 1 のみ ] ( ノード 2 は設定完了後 DB 起動前にノード 1 からベースバックアップでコピーします ) $ initdb -D /dbfp/pgdata/data -X /dbfp/pgxlog/pg_xlog --encoding=utf-8 --no-locale --data-checksums 13

14 2. レプリケーションユーザ作成 レプリケーションユーザを作成します [ ノード 1 のみ ] クライアント SQL 発行データ同期 Master Slave ノード #1 ノード #2 ユーザ情報を DB に入力するため PostgreSQL を起動します $ pg_ctl -w start ここで使用するユーザ ユーザ情報を入力します ( 例 : ユーザ名 ="repuser" パスワード ="reppasswd") $ psql -c "CREATE ROLE repuser REPLICATION LOGIN PASSWORD 'reppasswd'" ユーザ作成後 DB を停止します $ pg_ctl stop 14

15 3. レプリケーションユーザのアクセス許可設定 レプリケーションユーザが DB にアクセスすることを許可する設定をします [ ノード 1 のみ ] $ vi $PGDATA/pg_hba.conf (: 省略 ) host replication repuser /32 md5 host replication repuser /32 md5 replication データベースに対してレプリケーションユーザの設定をします IP アドレスはノード 1 ノード 2 両系の値を設定します クライアント ノード #1 Master データ同期 このネットワークの IP アドレスを指定 Slave ノード #2 15

16 4. パスワードファイル設定 postgres ユーザの $HOME 配下にパスワードファイル (.pgpass) を作成し 設定します [ ノード 1 ノード 2] ( ノード 1 の設定 ) $ vi ~/.pgpass :5432:replication:repuser:reppasswd :5432:replication:repuser:reppasswd $ chmod 600 ~/.pgpass ( ノード 2 の設定 ) $ vi ~/.pgpass :5432:replication:repuser:reppasswd :5432:replication:repuser:reppasswd $ chmod 600 ~/.pgpass Master データ同期 ( /24).1.2 クライアント Slave 仮想 IP ノード #1.3 ノード #2 Pacemaker で管理する際の処理の都合により Master 側のノードに仮想 IP を割り当てます ( 仮想 IP の割当は Pacemaker により行います ) 16

17 5. 同期レプリケーション設定 同期レプリケーションの設定をします [ ノード 1 のみ ] $ vi $PGDATA/postgresql.conf (: 省略 ) listen_addresses = '*' hot_standby = on wal_level = hot_standby WALに書き込み情報量 hot_standby_feedback = on max_wal_senders = 4 WALを送信するためのプロセス数 wal_sender_timeout = 20s wal_receiver_status_interval = 5s wal_keep_segments = 32 WALを確保しておく量 max_standby_streaming_delay = -1 max_standby_archive_delay = -1 synchronous_commit = on WAL 書き込みが完了してからレスポンスを返す archive_mode = on archive_command = '/bin/cp %p /dbfp/pgarch/arc1/%f' restart_after_crash = off クラッシュ時の自動再起動の有効 / 無効 上記設定は全て必要ですが ポイントだけここで紹介します 尚 同期レプリケーションの送信側 受信側の指定は起動時に別途実施します 17

18 PostgreSQL 同期レプリケーション 設定完了! PostgreSQL 単体で HA クラスタを組むと思わぬ落とし穴が!! 18

19 PostgreSQL 同期レプリケーション起動停止方法 (1/2) PostgreSQL の同期レプリケーションを有効にした起動方法を紹介します HA クラスタでは同期レプリケーションの送信側 (Master) と受信側 (Slave) は適宜入れ替わることが想定されるため その都度設定を変更する必要があります ノード 1 の PostgreSQL を起動します [ ノード 1 のみ ] $ pg_ctl -w start ノード 1 からノード 2 へ $PGDATA をベースバックアップします [ ノード 2 のみ ] $ pg_basebackup -h U repuser -D $PGDATA -xlogdir=/dbfp/pgxlog/pg_xlog -X stream -P ノード 2 を Slave として起動するための設定をします [ ノード 2 のみ ] $ vi $PGDATA/recovery.conf standby_mode = 'on' primary_conninfo = 'user=repuser host= port=5432 application_name=node02' restore_command = '/bin/cp /dbfp/pgarch/arc1/%f %p' recovery_target_timeline = 'latest' 19

20 PostgreSQL 同期レプリケーション起動停止方法 (2/2) ノード 2 を Slave として起動します [ ノード 2 のみ ] $ pg_ctl -w start ノード 1 からノード 2 への同期レプリケーションを開始します [ ノード 1 のみ ] $ vi $PGDATA/postgresql.conf (: 省略 ) synchronous_standby_names = 'node2' $ pg_ctl reload PostgreSQL 停止する際は Slave 側から停止する必要があります Slave の PostgreSQL を停止します [ ノード 2 のみ ] $ pg_ctl stop $ rm $PGDATA/recovery.conf $ rm -rf $PGDATA/data /dbfp/pgxlog/pg_xlog /dbfp/pgarch/arc1/* Master の PostgreSQL を停止します [ ノード 1 のみ ] $ pg_ctl stop $ vi $PGDATA/postgresql.conf (: 省略 ) # synchronous_standby_names = 'node2' 設定削除 20

21 PostgreSQL 同期レプリケーション故障時の設定変更 同期レプリケーションしている状態で DB やノード等が故障した際は以下の様に設定を変える必要があります (Slave 故障時 ) データ同期 Master 故障 Slave ノード #1 ノード #2 Slave への送信設定削除 [ ノード 1 のみ ] $ vi $PGDATA/postgresql.conf (: 省略 ) # synchronous_standby_names = 'node2' 設定削除 $ pg_ctl reload (Master 故障時 ) 故障 Master データ同期 Slave Master へ昇格 [ ノード 2 のみ ] $ pg_ctl promote recovery.conf は自動的にファイル名変更 (recovery.done) され 無視されます ノード #1 ノード #2 21

22 PostgreSQL 同期レプリケーション故障時の設定変更 同期レプリケーションしている状態でDBやノード等が故障した際は以下の様に設定を変える必要があります 起動の毎にベースバックアップを行い (Slave 故障時 ) MasterとSlaveはそれぞれ別々の設定をし Master データ同期 Slave ノード #1 ノード #2 Master データ同期 故障 故障時はまた設定を変えるの?! (Master 人類にはまだ 故障時 ) 早過ぎたんだ!! 故障 Slave ノード #1 ノード #2 Slave への送信設定削除 [ ノード 1 のみ ] $ vi $PGDATA/postgresql.conf (: 省略 ) # synchronous_standby_names = 'node2' 設定削除 $ pg_ctl reload Master へ昇格 [ ノード 2 のみ ] $ pg_ctl promote recovery.conf は自動的にファイル名変更 (recovery.done) され 無視されます 22

23 PostgreSQL 同期レプリケーション故障時の設定変更 同期レプリケーションしている状態でDBやノード等が故障した際は以下の様に設定を変える必要があります 起動の毎にベースバックアップを行い (Slave 故障時 ) MasterとSlaveはそれぞれ別々の設定をし Master データ同期 Slave ノード #1 ノード #2 私が自動実行人類にはまだ (Master 故障時 ) 故障 Master 故障 するもの データ同期 Slave ノード #1 ノード #2 大丈夫 故障時はまた設定を変えるの?! 早過ぎたんだ!! Slave への送信設定削除 [ ノード 1 のみ ] $ vi $PGDATA/postgresql.conf (: 省略 ) # synchronous_standby_names = 'node2' 設定削除 $ pg_ctl reload Master へ昇格 [ ノード 2 のみ ] $ pg_ctl promote recovery.confは自動的にファイル名変更 (recovery.done) され 無視されます 23

24 この PostgreSQL の管理の難しさ Pacemaker と PG-REX 運用補助ツールにより 解決します! 24

25 Pacemaker と PG-REX 運用補助ツールを使用した操作 (1/4) Pacemaker と PG-REX 運用補助ツールを使用した場合 以下のコマンドを使用して保守に必要な操作を実行します Master 起動 # pg-rex_master_start Slave 起動 # pg-rex_slave_start PG-REX 停止 # pg-rex_stop Master/Slave 手動系切替 # pg-rex_switchover アーカイブログの整理 ( 不要となったアーカイブログを削除 ) # pg-rex_archivefile_delete 25

26 Pacemaker と PG-REX 運用補助ツールを使用した操作 (2/4) Pacemaker と PG-REX 運用補助ツールを使用した場合 起動手順は以下の様になります ノード1(Master) 1. PostgreSQL 起動 5. synchronous_standby_names 設定ノード1(Master) 1. Master 起動 (# pg-rex_master_start) 起動時 ノード 2(Slave) 2. ベースバックアップ 3. recovery.conf 設定 4. PostgreSQL 起動 PacemakerとPG-REXを導入すると ノード2(Slave) 2. Slave 起動 (# pg-rex_slave_start) 26

27 Pacemaker と PG-REX 運用補助ツールを使用した操作 (3/4) Pacemaker と PG-REX 運用補助ツールを使用した場合 停止手順は以下の様になります ノード1(Master) 3. PostgreSQL 停止 4. synchronous_standby_names 削除ノード1(Master) 2. PG-REX 停止 (# pg-rex_stop) 停止時 ノード 2(Slave) 1. PostgreSQL 停止 2. recovery.conf 削除 PacemakerとPG-REXを導入すると ノード2(Slave) 1. PG-REX 停止 (# pg-rex_stop) 27

28 Pacemaker と PG-REX 運用補助ツールを使用した操作 (4/4) 故障時に必要だった以下の手順は全て自動で行うため 操作不要になります (Slave 故障時 ) データ同期 Master 故障 Slave ノード #1 ノード #2 Slave への送信設定削除 [ ノード 1 のみ ] $ vi $PGDATA/postgresql.conf (: 省略 ) # synchronous_standby_names = 'node2' 設定削除 $ pg_ctl reload (Master 故障時 ) 故障 Master データ同期 Slave Master へ昇格 [ ノード 2 のみ ] $ pg_ctl promote ノード #1 ノード #2 28

29 これらを実現するには アプリケーションの管理方法を 設定する必要があります 29

30 まずは Pacemaker から Pacemaker のインストールや基本設定は以下をご参照ください 試して覚える Pacemaker 入門リソース設定編 30

31 Pacemaker のリソース管理設定の流れ Pacemaker のリソース ( アプリケーション ) 管理は CRM ファイルと呼ばれるファイルを作成して設定します CRM ファイルは以下の手順で作成できます ファイル転送 Linux 端末 Pacemaker インストール時に配置される以下のファイルを Windows 端末に転送 # ls /usr/share/pacemaker/pm_crmgen/pm_crmgen_env.xls pm_crmgen_env.xls にリソース構成や管理方法を入力 ファイル転送 Windows 端末 Linux 端末 Excel のシートを CSV ファイルで保存し Linux 端末に転送 Pacemaker のツールコマンドを使用して CRM ファイルに変換 # pm_crmgen -o CRM ファイル名 CSV ファイル名 31

32 Pacemaker のリソース管理設定 pm_crmgen_env.xls は以下の様な表が記述されており 青の枠線の中を埋めて設定します # pm_crmgen 環境定義書ファイル形式バージョン : 2.2 # 表 1-1 クラスタ設定 クラスタ ノード属性 NODE uname ntype ptype name value # ノード名 ノード種別 パラメータ種別 項目 設定内容 備考 # 表 2-1 クラスタ設定 クラスタ プロパティ PROPERTY name value # 項目 設定内容 概要 備考 no-quorum-policy ノード数によるリソース割当て stonith-enabled 障害ノード対処 (STONITH 制御 ) startup-fencing 起動時に状態不明ノードへSTONITH 詳細については以下の OSC セミナー資料で説明しているのでご参照ください 試して覚える Pacemaker 入門リソース設定編 32

33 PG-REX リソース管理設定 PG-REX の場合は以下のサイトから設定済みの pm_crmgen_env.xls が入手できるため こちらを修正するのが簡単です PG-REX プロジェクト : 以下の橙色で塗りつぶされているセルを環境に合わせて修正してください # 表 クラスタ設定 Primitive リソース (id=vip-master) # PRIMITIVE P A type # パラメータ種別項目設定内容概要 O id class provider type リソース ID vip-master params type # オペレーションタイムアウト値監視間隔 on_fail( 障害時の動作 ) 起動前待機時間 start monitor stop name class provider type ocf heartbeat IPaddr2 value ip PostgreSQL(Master) 接続用仮想 IP アドレス nic bond0 同デバイス名 cidr_netmask 24 同ネットマスク timeout interval on-fail start-delay 60s 0s restart 60s 10s restart 60s 0s block 概要 PostgreSQL(Master) 接続用仮想 IP 割当 備考 pm_crmgen_env.xls は STONITH 構成と NoSTONITH 構成のものが用意されてあります 運用環境では STONITH 構成を推奨しますが 動作確認用であれば NoSTONITH 構成が環境の制約もなく構築しやすいです 33

34 PostgreSQL の Slave へのデータベース接続 PostgreSQL は Slave でも DB を参照することが可能です PG-REX 用設定済み pm_crmgen_env.xls では DB 更新 / 参照用の仮想 IP とは別に DB 参照専用の仮想 IP を割り当てて 上記機能を活用できるようにしています DB 更新 / 参照 DB 参照 仮想 IP ( 更新 / 参照 ) データ同期 仮想 IP ( 参照 ) Master Slave ノード #1 更新 / 参照 ノード #2 参照 DB データ ローカルディスク DB データ ローカルディスク 34

35 PG-REX における仮想 IP の管理 PG-REX にて Pacemaker が割り当てる仮想 IP は合計で以下の 3 つであり それぞれ vip-master vip-slave vip-rep と名称しています DB 更新 / 参照 vip-master: DB を更新 / 参照する際にアクセスするための仮想 IP サービス LAN 上に割り当てる vip-slave: DB を参照する際にアクセスするための仮想 IP サービス LAN 上に割り当てる vip-rep: データレプリケーションする際に Master にアクセスするための仮想 IP データ転送用 LAN 上に割り当てる DB 参照 DB 更新 / 参照 DB 参照 vip-master 故障 Master データ同期 vip-rep vip-slave Slave 故障 Master vip-master vip-slave vip-rep Master ノード #1 ノード #2 ノード #1 ノード #2 35

36 ( 参考 ) PG-REX で Pacemaker が管理するリソース構成 シェアードディスク構成 PostgreSQL 仮想 IP(S-LAN) Filesystem シェアードディスク排他制御 リソースグループとして一括制御 制約 PG-REX ( シェアードナッシング構成 ) 仮想 IP(S-LAN) 仮想 IP(D-LAN) PostgreSQL (Master) 制約 リソースグループとして一括制御 Master/Slave リソースとして制御 PostgreSQL (Slave) ハードウェア監視など ハードウェア監視など ハードウェア監視など 制約 ハードウェア監視など 起動 / 停止 / 監視 起動 / 停止 / 監視 起動 / 停止 / 監視 起動 / 停止 / 監視 Pacemaker Pacemaker Pacemaker Pacemaker ノード #1 ノード #2 ノード #1 ノード #2 試して覚える Pacemaker 入門リソース設定編 ではこの構成を構築しています 上記では以下の様な略称で記述しています サービスLAN S-LAN データ転送用 LAN D-LAN 36

37 続いて PG-REX 運用補助ツール 37

38 PG-REX 運用補助ツールのインストール 設定 (1/2) PG-REX 運用補助ツールも先ほどの pm_crmgen_env.xls と同様に以下から入手できます PG-REX プロジェクト : 必要となるパッケージ ( バージョンは入手時の最新のものを選択してください ) Net_OpenSSH-*.rpm IO_Tty-*.rpm pg-rex_operation_tools_script-*.rpm ダウンロードしたパッケージを以下の順にインストールします [ ノード 1 ノード 2] # rpm -ivh Net_OpenSSH-*.rpm # rpm -ivh IO_Tty-*.rpm # rpm -ivh pg-rex_operation_tools_script-*.rpm 38

39 PG-REX 運用補助ツールのインストール 設定 (2/2) インストールすると以下のファイルが配置されます /usr/local/bin pg-rex_master_start pg-rex_slave_start pg-rex_stop pg-rex_switchover pg-rex_archivefile_delete /etc pg-rex_tools.conf PG-REX 運用補助ツールの設定ファイルを修正します [ ノード 1 ノード 2] # vi /etc/pg-rex_tools.conf D-LAN_IPAddress = , Archive_dir = /dbfp/pgarch/arc1 STONITH = disable VIP_SLAVE = enable (: 省略 ) MasterノードとしてPacemakerを起動するコマンド SlaveノードとしてPacemakerを起動するコマンド 自ノードのPacemakerを停止するコマンド MasterとSlaveを系切替するコマンド 不要なアーカイブログを選定して削除するコマンド PG-REX 運用補助ツールの設定ファイル ( その他 /usr/local/share/perl5/pgrex 等に common ファイル等が配置されます ) 両系のデータ転送用 LANのIP アーカイブログディレクトリ STONITHの使用有無 仮想 IP vip-slaveの使用有無 39

40 PG-REX 完成!! 40

41 PG-REX の動作確認方法 (1/3) PG-REX は Master を先に起動し 起動完了後に Slave を起動します Master を起動します [ ノード 1 のみ ] # rm /var/lib/pgsql/tmp/pgsql.lock 前起動時に正常停止できなかった場合に残存される起動禁止フラグです # pg-rex_master_start PG-REX9.6_pm_crmgen_env.crm pm_crmgen_env.xls から生成した CRM ファイル名を指定します 上記 Master 起動完了を確認後 Slave を起動します [ ノード 2 のみ ] # rm /var/lib/pgsql/tmp/pgsql.lock # pg-rex_slave_start 41

42 PG-REX の動作確認方法 (2/3) 動作確認用の DB とユーザ テーブルを作成します [ ノード 1 のみ ] $ createdb testdb $ createuser user1 $ psql -d testdb -U user1 -c "CREATE TABLE bar (id int, name varchar)" $ psql -d testdb -U user1 -c "INSERT INTO bar VALUES (1, 'apple')" $ psql -d testdb -U user1 -c "SELECT * FROM bar" id name apple ノード 2 で入力したテーブルが参照できることを確認します [ ノード 2 のみ ] $ psql -d testdb -U user1 -c "SELECT * FROM bar" id name apple 42

43 PG-REX の動作確認方法 (3/3) 停止時は以下のコマンドを使用してSlaveから順に停止します Slaveを停止します [ ノード2] # pg-rex_stop Master を停止します [ ノード 1] # pg-rex_stop 43

44 Linux-HA Japan のブースにて PG-REX のデモ環境を用意しています 是非お越しください!! 44

45 さいごに ( 宣伝 1) Linux-HA Japan URL Pacemaker 関連の最新情報を日本語で発信 Pacemaker のダウンロードもこちらからどうぞ ( インストールが楽なリポジトリパッケージを公開しています ) 45

46 さいごに ( 宣伝 2) 日本における HA クラスタについての活発な意見交換の場として Linux-HA Japan 日本語メーリングリスト も開設しています Linux-HA-Japan ML では Pacemaker Heartbeat3 Corosync DRBD など HA クラスタに関連する話題は歓迎! ML 登録用 URL の メーリングリスト をクリック ML アドレス linux-ha-japan@lists.osdn.me スパム防止のために 登録者以外の投稿は許可制です 46

47 さいごに ( 宣伝 3) PG-REX URL PG-REX の構築手順書や pm_crmgen_env.xls PG-REX 運用補助ツールを提供しています 本セミナーでは説明できなかった詳細内容も上記手順書に詳しく書いてあるので是非読んでください! 47

48 ご清聴 ありがとうございました 48