さいきんのMySQLに関する取り組み（仮）

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● わりと MySQL のひと ● 3.23.58 から使ってる ● むかしは Resource Monitoring も力入れてやってた ● ganglia & rrdcached の（たぶん）ヘビーユーザ ● というわけで、自分は Monitoring を大事にする ● 一時期は Flare という OSS の bugfix などもやってた ● さいきんは、ハードウェアの評価をしている時間が長かった ● たまに Linux の TCP プロトコルスタックについて調べたりもする 2

Slide 3

Slide 3 text

Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、古くからオンプレミス環境で、 MySQL をヘビーに使ってきました。 ● 過去に、一部のサービスを AWS に移行した際、マネージドサービスだけでなく、 EC2 でも MySQL を使う構成にしまして、ここ数年でいくらかノウハウが溜まってきた気もします。 ● また、数年先を見据えて取り組んでいることもあります。 ● 今回は、そういったあたり、お話させていただければと思います。 ● わたしはいろいろ変なこと考えてますが、オンプレおじさんなので ● パブリッククラウドでは、若手たちが創意工夫して頑張ってくれてます。本日のお話 3

Slide 4

Slide 4 text

Copyright © GREE, Inc. All Rights Reserved. ● MySQL の話をする際、 InnoDB の話を避けるのが難しいので ● まだ読まれたことのない方は ● 次の資料もあわせて読んでいただけると、よりわかりやすいかと思います ● さいきんの InnoDB Adaptive Flushing （仮） ● できればこちらひととおり読んでいただけると、より理解が深まるかと思います ● https://www.slideshare.net/takanorisejima/ 本日のお話の補足資料 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Copyright © GREE, Inc. All Rights Reserved. ● GREE のサービスは歴史が古い ● むかしから動いてる MySQL のサーバは、かなり sharding されていた ● 2000年代、GREE は SAS HDD 146GB 15krpm * 4本使った RAID10 の前提で、データベースを設計してるところが多かった ● そういう HDD でも動くように、データベースのサイズは 100-200GB 以下のものが多かった ● ４年くらい前までは、 MySQL 含め、ほとんど HDD で動いていた ● ioDrive ないこともなかったが、全体の数％だった ● かつてほとんど HDD で動いていたことを考えると、最近の block device は桁違いに性能が良くて、性能面ではとても楽。むかしの GREE のサーバ 7

Slide 8

Slide 8 text

Copyright © GREE, Inc. All Rights Reserved. ● ここ数年かけて、ほぼ SATA SSD の環境になった。 ● いくらか ioMemory 残っているけど、 Endurance 的には、 1DWPD から 3DWPD 程度の SSD がほとんど。 ● ストレージの appliance は使っていない。SSD は SATA直結。 ● disk I/O のためにネットワークの traffic が発生しないので、ネットワーク機器が安く上がる。 ● private cloud はやっていない。すべてベアメタル。 ● 仮想化しないと、ハードウェアから、 kernel - TCP プロトコルスタック - MySQL までの各レイヤーに対して、調査がしやすい。 ● 日本では、ランニングコストのうち、電気代の比率が高い。如何にして消費電力効率を最適化するか、という戦略を取っている。 ● NVMe ではなく SATA の SSD 使っているのも、消費電力が低いから。さいきんの弊社のオンプレミス環境 8

Slide 9

Slide 9 text

Copyright © GREE, Inc. All Rights Reserved. ● 新しいサービスは、パブリッククラウドで立ち上げている。海外展開がしやすかったり、インスタンスの数を柔軟に調整しやすいなどのメリットが有る。 ● その他、かつてオンプレで動いていたサービスの大部分、台数にして 2000台以上のサーバを、 AWS に移行してから数年が経った。 ● 計画停止しにくいものをオンプレで安定稼働させつつ、計画停止できるものを、パブリッククラウドに移行した。 ● オンプレから移行してきたサービスは、マネージドサービスも活用しているが、 EC2 で MySQL を立てて運用しているところが多い。 ● MySQL を failover させる仕組みは、パブリッククラウドを使う前から内製していたので、 failover をマネージドサービスに任せなくても運用できる。パブリッククラウドの利用状況 9

Slide 10

Slide 10 text

Copyright © GREE, Inc. All Rights Reserved. ● 現状、MySQL 5.6 か 5.7 を使っている。大部分が 5.7。 ● MySQL 8.0 は検証中。 ● MySQL の Extended Support の期間を意識して新しいバージョンに移行するというより、可能であれば新しいメジャーバージョンに移行していきたいと考えている。 ● MySQL のメジャーバージョンは、 Extended Support が終了するまでの間、 GA が出てからだいたい８年くらいは、 security update がリリースされる。弊社のMySQL利用状況 10

Slide 11

Slide 11 text

Copyright © GREE, Inc. All Rights Reserved. ● 次のようなものが挙げられる ● Multi Source Replication など、コスト削減につながる機能が追加される。 ● Multi Source Replication のおかげで、 DB の統合がとても楽になった。 ● バージョンを追うごとに、 InnoDB が mutex の競合に強くなっている。メジャーバージョンアップにより、 InnoDB をより堅牢強固にすることができる ● アプリケーションの不具合や障害などで、意図せず InnoDB が高負荷状態になってしまうことがたまにある。しかし、さいきんの InnoDB は、 innodb_thread_concurrency などを適切にチューニングしておけば、それでもなんとか持ちこたえてくれたりする。 ● ある程度バージョンアップに追随しておけば、 security update や大きい bug fix 来たときなどに、対応しやすい。 ● 環境の変化に追随しやすくする ● 現状、GTID や Group Replication がなくても運用できているが、将来はあった方が便利だろうし MySQL をバージョンアップする理由 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Copyright © GREE, Inc. All Rights Reserved. ● MySQL は portability が高い。 ● オンプレから EC2 に移行できたのも、 portability が高かったから。 ● 引き続き EC2 でも素の MySQL を運用するならば、今後の状況に応じて、いろいろな選択肢を残すことができる。 ● MySQL は、時代の変化を見据えつつ、機能や性能を改善している。 ● かつて私が入社した頃は、オンプレでは HDD で MySQL が動いていて、 MyISAM で動作しているサーバが、今よりも遥かに多かった。 ● それから、 InnoDB やレプリケーションなどが改善された結果、最近の HW の性能を活かせるように進化してきたので、 MySQL 一台あたりの性能が改善し、むかしより集約して台数を減らしやすくなった。 EC2 で素の MySQL を使うメリット・その１ 13

Slide 14

Slide 14 text

Copyright © GREE, Inc. All Rights Reserved. ● MySQL は、 Extended Support の期間や、開発のサイクルが明示されている。 ● これは重要。何気に超重要。 ● パブリッククラウドといえど、 CPU の世代が新しくなると、 kernel や OS を新しくしたくなる。古い kernel で新しい CPU 使うと、追加された拡張命令で不具合ふんだりすることもある。 ● 長年運用しているサービスで新しい OS に移行するのは、工数がかかる。 OS の移行スケジュールと併せて、 MySQL などのアップデートスケジュールを考えていきたい。 ● 長期運用しているサービスであれば、 OS 入れ替えたりするロードマップなどはちゃんと考えていきたいので、ライフサイクルがわかりやすい MySQL は、とてもありがたい存在。 ● MySQL は一つのメジャーバージョンに対して８年くらいはメンテンナンスが続く。長期運用しているサービスとしては、非常に助かる存在。 EC2 で素の MySQL を使うメリット・その２ 14

Slide 15

Slide 15 text

Copyright © GREE, Inc. All Rights Reserved. ● MyISAM など InnoDB 以外を使っていても、そのまま動かせる。 ● MySQL 5.1 以前からやってるサービスでは、古いバックアップデータをたくさん保存するために、 ARCHIVE engine の DB が残っていたりする。 ● マネージドサービスと異なり、何かあったらソースコードを読めばいい。 ● MySQL で気になることがあれば、 MySQL のソースコードや WorkLog 読むし ● TCP 的によくわからないことがあれば、 RFC や Linux の kernel 読むし ● OS まるごとチューニングしたり、調査できる余地があるので、何かあったときに対応の選択肢が多い。 ● マイナーバージョンアップなどの決定権を、自分たちで持てる。 ● バージョンアップのスケジュールを、自分たちで管理できるのは楽でいい。 EC2 で素の MySQL を使うメリット・その３ 15

Slide 16

Slide 16 text

Copyright © GREE, Inc. All Rights Reserved. ● slave だけ先行して新しいバージョンを試しやすい。 ● 例えば、 MySQL 5.6 の master に 5.7 の slave をぶら下げて、参照を 5.7 の slave に向けるような対応がやりやすい。 ● DB の統合がやりやすい。 ● instance のスケールアップをしつつ、 DB を統合して台数を削減したいとき、 MySQL 5.7 の Multi Source Replication がとても使いやすい。 ● 何か気になることあったとしても、マネージドサービスと違ってソースコード読めるので、安心して使える。仮に DB 統合して、想定より高負荷になったとしても、ソースコード読めばいい。 EC2 で素の MySQL を使うメリット・その４ 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright © GREE, Inc. All Rights Reserved. ● 弊社の一部のサービスは、 EC2 で MySQL を運用していたので、かなり影響を受けてしまった。 ● EC2 で MySQL を使っているところは、 EBS に MySQL の datadir をおいて運用しているところがほとんどだったので、多くが EBS の障害に巻き込まれた。 ● root volume 、あるいは datadir の volume のいずれかの EBS がハングアップすると、そのインスタンスは切り捨てるしかなかった。半死の mysqld が同時に多数発生した。 ● OS再起動かかったインスタンスもあった。応答しなくなる mysqld もあった。zombie process になってしまう mysqld もでた。障害が長時間に及んだので、 failover した先のインスタンスで、 EBS が再びハングアップしてしまうこともあった。 2019-08-23 の東京リージョン大規模障害 18

Slide 19

Slide 19 text

Copyright © GREE, Inc. All Rights Reserved. ● もともと、 MySQL の replication は、ネットワークの断に強いという認識があった。 ● master <-> slave 間の replication の接続切れたとしても、自動で再接続できるので ● AZ 内で大規模ネットワーク障害が発生しても、ほとんどの replication は自動で復旧できるという想定だった。 ● かつて、何度か予期せぬ瞬断などは経験したが、 replication は自動復旧できていた。 ● しかし、大規模な EBS 障害は、厳しいものだった ● datadir をおいている volume がハングアップすると、 mysqld は使い物にならなくなる ● 複数の AZ でレプリケーションしていたし、定期的に S3 にバックアップしてたので、いちおう復旧はできたのだが MySQL は、断に強いと期待していた 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © GREE, Inc. All Rights Reserved. ● 弊社は AWS で MySQL を使うとき、ほとんど EBS は gp2 で運用している。 ● たまに I3 インスタンス使っているところもあるが ● baseline で 1000IOPS 出なくても動く DB は、少なからずある ● かつてオンプレでは HDD で動いていた DB を、 EC2 で Multi Source Replication で統合していったわけで。 gp2 でも HDD よりは性能が良いので。 ● gp2 で動かせると、 IO 課金発生しないので、コスト削減に繋がる。 ● gp2 は volume size に比例して、ある程度 IO の性能は向上するが、 volume size は、なるべく必要最小限なままに留めている。その方が安いから。 EC2向けにInnoDBのIOを最適化する・その１ 25

Slide 26

Slide 26 text

Copyright © GREE, Inc. All Rights Reserved. ● MySQL の master も slave も EBS で動かせると、datadir の snapshot とるのが楽になる。 ● 弊社は伝統的に、アプリケーションサーバから参照されない slave を配置している。 MySQL のバックアップ取るときは、アプリケーションサーバから参照されない slave で mysqld を停止して、 datadir を tar ball に固めていた。 ● EBS であれば、tar ball 取る代わりに、 datadir の volume をまるごと snapshot 取ればいい。 ● EBS snapshot は S3 にバックアップされるので、（ S3 は少なくとも3つの AZ でデータが保存されるから）信頼性も高い。 ● slave 構築する際は、その snapshot から datadir 復元できる。 ● EBS snapshot で datadir の snapshot 取る仕組みであれば、 snapshot 取るための instance は、とても安価な instance で動かしても良い。 ● 具体的には、使えるところは T 系ファミリーの instance を使っている。 ● このあたり、若者たちが創意工夫して頑張ってくれました。 EC2向けにInnoDBのIOを最適化する・その2 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Copyright © GREE, Inc. All Rights Reserved. ● volume size に比例して I/O の性能が変わる ● 1000GiB 未満の場合、 Credit balance 使い切ると I/O の性能が劣化する ● EBS は、物理サーバに内蔵されているエンタープライズ向け SSD と比べると、 latency などが不安定になることもある。 ● volume size が小さくても Credit balance 残ってれば 3000IOPS でるので、ピークタイムに Credit balance 使い切らなければ良い。まずは gp2 について振り返る 28

Slide 29

Slide 29 text

Copyright © GREE, Inc. All Rights Reserved. ● IOPS だけでなく、以下のメトリックなども取得する ● VolumeQueueLength, VolumeTotalWriteTime, VolumeTotalReadTime, BurstBalance ● I/O が重くなって高負荷状態なサーバがあった場合、 I/O クレジット使い切っているのか、 I/O にかかっている時間が異常なのかを切り分けられるようにする ● read/write にかかっている時間が想定よりも長いのであれば、そのサーバは諦めてサービスから切り離すなどする ● また、 I/O クレジット使い切りそうなサーバがあるならば、 VolumeSize の見直しなど行うそして、 gp2 の monitoring をカッチリやる 29

Slide 30

Slide 30 text

Copyright © GREE, Inc. All Rights Reserved. ● I/O を削減する方向で、InnoDB のチューニングを行う ● 例： ● innodb_log_file_size=1G ● innodb_io_capacity=100 ● innodb_flush_log_at_trx_commit=2 ● innodb_flush_neighbors=0 ● skip_innodb_doublewrite=1 ● サービスに投入する master や slave は、InnoDB のクラッシュリカバリに期待しない。台数を並べて冗長性を持たせる。 ● EBS で障害が発生すると、そもそもクラッシュリカバリも実施できないから、台数を並べて、耐障害性を確保する。 ● また、 MySQL 側だけでなく、アプリケーションサーバ側の log を収集しておくなど、別の手段を担保しておくべきである。 ● いずれにせよ、アプリケーションサーバの log は、サポート業務や Analytics のために収集する必要があるし。 gp2 の I/O クレジットを節約するために 30

Slide 31

Slide 31 text

Copyright © GREE, Inc. All Rights Reserved. ● とにかくちょっとでも I/O の burst を避けるために、 innodb_adaptive_flushing_lwm を下げて、ちょっとずつ flush させる。 ● 例： innodb_adaptive_flushing_lwm=5 ● InnoDB Adaptive Flushing で dirty page の flush がはじまっても、innodb_adaptive_flushing_lwm を下げていると、一秒間に flush される page の数を減らすことができる。 ● innodb_adaptive_flushing_lwm を下げると、 write combining が効きにくくなるかもしれないが、それは innodb_log_file_size を増やせば良いだけのこと。 ● 実際に I/O の burst が発生したとき、 gp2 だと高負荷になってしまうケースが有ったので、それの対策で lwm 変えた。さらに I/O を節約 31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Copyright © GREE, Inc. All Rights Reserved. ● 古い DB で InnoDB 以外の storage engine も使っていたりするので、EC2 で MySQL を使うメリットは、引き続きありますし。 ● EBS snapshot で MySQL のバックアップを取るというのは、有効な手法だと思うので、おそらく今後も使う気がしていますが。 ● MySQL の耐障害性をさらに改善することについて、取り組んでいく必要性を感じています。 ● 現時点でも、 master の DB が稼働しているのとは別の AZ に slave 置いて、 S3 にバックアップ取るようにするなどしていますが ● 中途半端にハングアップしている（アクセスできなくなっている） EBS が大量発生した場合、なかなか対応が難しい、クラッシュリカバリで救うことも難しそうなので ● じっくり対応を考えていきたいと思っています。 ● MySQL は portability が高く、考えられる余地も多いですし。 EBS 障害を受けて、今後の取り組み 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、オンプレでは CPU の clock を P0 state で固定して使っている。 ● アプリケーションの response time 改善のため、 clock を落としたくない。 ● しかし、パブリッククラウドでは、ホストごと専有しない限り、 CPU の clock を固定することは難しい。 ● そのため、パブリッククラウドでも CPU の clock をメトリックとして保存するようにしていたのだが。 ● ある日、特定の MySQL の slave だけ CPU の clock がやたら下がってしまい、過負荷になってしまったことがあった。 ● それ以来、 CPU の clock が明らかに低いインスタンスがあれば、 alert を上げるようにしてもらっている。 CPU の clock を監視する 38

Slide 39

Slide 39 text

Copyright © GREE, Inc. All Rights Reserved. ● オンプレと比べて、パブリッククラウドでは、どうしてもパケットの再送などが増えてしまう。 ● アプリケーションサーバだけでなく、 MySQL でも、 /proc/net/netstat における、例えば以下のような metric は注視している ● ListenOverflows ● TCPFastRetrans ● TCPTimeouts ● TCPTimeWaitOverflow ● TCPSynRetrans TCP のメトリック 39

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、MySQL5.1のころから binlog_format=ROW 使っているサービスもあるんですが、ほとんどは binlog_format=STATEMENT でした。 ● binlog_format=STATEMENT だと、 TRIGGER で online schema change やりやすいので ● binlog_format=STATEMENT で困っているかというと、そんなに困ってないんですが ● ただ、さいきんの MySQL は Online DDL が改善されてきましたし、むかしほど、サービス無停止で online schema change する必要性もなくなってきているので ● 中長期的に考えて、 statement-based replication（SBR）から row-based replicaton（RBR）への移行を進めています。将来を見据えて 42

Slide 43

Slide 43 text

Copyright © GREE, Inc. All Rights Reserved. ● ドキュメントには、次のような記述があります。 ○ 5.2.4.2 バイナリログ形式の設定 ■ レプリケーションの進行中にマスター上のバイナリロギング形式を変更したり、スレーブ上でそれを変更しなかったりすると、予期しない結果を招いたり、レプリケーションの失敗を招くことがあります。 ● といったことを踏まえると、安定して binlog_format=ROW にするのであれば SBR から RBR への移行 43

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Copyright © GREE, Inc. All Rights Reserved. ● binlog_format=ROW が導入された歴史的経緯 ● binlog_format が起因で replication が止まるのはどのような場合か、また、ソースコード的にはどのあたりでエラーになるのか ● binlog_format=ROW のとき、 binlog event はどのようにしてbinlog に出力されるのか。 ● binlog_format=ROW のとき、 online schema change はどのように対応すればよいか ● binlog_format=ROW のとき、 master と slave で column の型が異なる場合は、ソースコード的にどのように対処されているか ● binlog_row_image についてくわしく ● などなど事前に調べたこと 51

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Copyright © GREE, Inc. All Rights Reserved. ● References ○ http://mysqlmusings.blogspot.com/2012/06/binary-log-group-commit-in-mysql-56.html ○ https://bugs.mysql.com/bug.php?id=50935 ○ https://dev.mysql.com/worklog/task/?id=4033 ○ https://dev.mysql.com/worklog/task/?id=5404 ○ https://bugs.mysql.com/bug.php?id=23051 ○ https://dev.mysql.com/worklog/task/?id=3339 ○ https://dev.mysql.com/worklog/task/?id=3303 ○ https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-5.html ○ https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html ○ https://bugs.mysql.com/bug.php?id=85371 ○ https://dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html ○ https://dev.mysql.com/worklog/task/?id=5092 ○ https://dev.mysql.com/worklog/task/?id=3915 ○ https://dev.mysql.com/doc/internals/en/table-map-event.html RBRに関する資料の一部 53

Slide 54

Slide 54 text

Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、サービス無停止で、master 切り替えも行わず ● 稼働中の MySQL に SET GLOBAL binlog_format=ROW を実施して ● だいたいの DB が、 SBR から RBR への移行を完了しました。 ● 一部の DB は、未だ binlog_format=STATEMENT だったりしますが、今後、じっくり取り組んでいきたいと思います ○ 例： ■ 古いシステムで、 binlog_format=STATEMENT の binlog を監査に使っているものがあるので、そういったところは別途対応が必要その結果 54

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Copyright © GREE, Inc. All Rights Reserved. ● 現時点において、（個人的に）Group Replication に期待しているところ大なので、いつか移行したいと思ってます。 ● 現在、 MySQL を failover させるためのソフトウェアを社内で内製しているのですが、 Group Replication へ移行することで、そのメンテナンスコストを減らせないかな？という期待があります。 ● また、 Group Replication を導入したいという、とても大きな理由が一つあります。 Group Replication の導入 57

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Copyright © GREE, Inc. All Rights Reserved. ● IaaS を使っていると、host 側のメンテナンス、あるいはセキュリティアップデートで、パブリッククラウド事業者から reboot を求められることがあります。 ● IaaS で動いている mysqld の台数が多いと、その対応コストが看過できないものになります。 ● アプリケーションサーバは auto scaling のついでに入れ替えたりできますが、 mysqld のようにデータを永続化するものでは、そうもいきません。 ● オンプレでも security update のために kernel update することはあります。しかし、余裕を持って reboot のスケジュールを自社で考えることが、パブリッククラウドではできないこともあります。 ● 弊社では、 master の mysqld がメンテナンス対象になった場合、サービス無停止で切り替えたい場合、切り替え先の master & slave のセットを、まるごと新規に構築しています。 scheduled reboot の対応コスト削減 60

Slide 61

Slide 61 text

Copyright © GREE, Inc. All Rights Reserved. ● 最近の MySQL の Group Replication は、 Single-Primary Mode と Multi-Primary Mode を、動的に切り替えられるようになりました ● 普段は Single-Primary Mode で運用して ● primary server がメンテナンス対象になったときだけ、一時的に Multi-Primary Mode に切り替えて、 primary server を Group Replication から外せばいいかな、と ● これができると、 IaaS で mysqld 運用するのがグッと楽になるかと ● Group Replication は今後も継続的に改善されていく機能でしょうから、じっくり腰を据えて取り組んでいければ、と考えています Group Replication に期待すること 61

Slide 62

Slide 62 text

Copyright © GREE, Inc. All Rights Reserved. ● EBS snapshot で datadir のバックアップを取るついでに、 instance の stop & start ができないか ● scheduled reboot の対象になっても、自動的に対応できるようになるから ● i3 や i3en などのインスタンスを、もっと活用できないか ● いままでは gp2 で安価に運用してきたが、 EBS 障害への耐性を上げたいので ● NVMe 一本専有できるインスタンスを使って、 MySQL の datadir をそちらに置けないかと。 ● root volume も datadir も EBS だと、どちらか一方がハングアップしただけで使えなくなる。しかし、 datadir が local の storage だと、root volume がハングアップしない限りは、 EBS の障害に耐えられるようになる。 ● また、i3 の NVMe はかなり高性能なので、 Multi-Threaded slave と組み合わせつつ、台数を集約できそうな余地はある。その他、EC2でやっていきたいこと 62