MySQLやSSDとかの話　その後

Copyright © GREE, Inc. All Rights Reserved.
MySQLやSSDとかの話
その後
Takanori Sejima

自己紹介
● わりとMySQLのひと
● 3.23.58 から使ってる
● むかしは Resource Monitoring も力入れてやってた
● ganglia & rrdcached の（たぶん）ヘビーユーザ
● 6年くらい前から使い始めた
● gmond は素のまま使ってる
● gmetad は欲しい機能がなかったので patch 書いた
● webfrontend はほぼ書き直した
● あとはひたすら python module 書いた
● ganglia じゃなくても良かったんだけど、とにかく rrdcached を使いたかった
● というわけで、自分は Monitoring を大事にする
● 一時期は Flare という OSS の bugfix などもやってた

● 古いサーバを、新しくてスペックの良いサーバに置き換えていく際、いろい
ろ工夫して集約していっているのですが
● 実際にいろいろ使ってきて見えてきたことや、今後について考えることも増
えてきたので
● 今日はそんなお話をしようと思います
● 今回はあまりMySQLの話はありません
● わたしはいろいろ変なこと考えてますが
● 引き続き、細かいところは優秀な若手の実働部隊が頑張ってくれてます
本日のお話

● まだ読まれたことのない方は
● 後日、あわせて読んでいただけると、よりわかりやすいかと思います
● 過去の資料
● MySQLやSSDとかの話　前編
● MySQLやSSDとかの話　後編
本日のお話の補足資料

まずはおさらい

● GREEのサービスは歴史が古い
● むかしから動いてるMySQLのサーバは、かなり sharding されていた
● 2000年代、GREEは SAS HDD 146GB 15krpm * 4本使ったRAID10の前提で、
データベースを設計してるところが多かった
● 15krpm だとそれくらいの容量の製品しかなかった
● そういうストレージでも動くように、データベースのサイズは100-200GB以下のものが
多かった
● わたしが入社した2010年のころは、よくサービスささっていて、各エンジニ
アが協力して改善してた
● アプリケーションレイヤーでがんばってもらったり、力の限りsharding したり
かつてのGREEのサーバ

● HDD前提の設計だと、サーバの台数が増えまくる。電力効率も良くない
● HDD前提のDBだと、HDDがボトルネックになって、CPU使い切れないケースが多い
● HDDを基準に sharding していくと、一台のサーバでさばく qpsはどうしても低くなって、
CPU使用率はあまり上げられない
● むかしは積めるDRAMの量も少なかったし、メモリの帯域はそれほど多くなかった
● そもそもHDDがそれなりに電力を食う
● SAS 15krpm だと一本で 10W 以上かな？
● 結果、ラック単位で見たときに消費電力効率が良くない
● HDDの占める消費電力がそこそこ大きかった時代
● そんな中、 SSD の価格は下がり続けており
● SSD の進化にあわせてサーバの構成を見直すことで、ランニングコストを
削減し、サービスの競争力を維持しようと試みた
サービスとしては改善したんだけど

そして着手した

● Fusion-IO 流行し始めたころ、調達できたのは ioDrive MLC 320GB
● ほとんどのDBは、HDDでも動くように sharding など工夫していたから、
320GB という少ない容量は使いドコロが難しかったので
● 長考して長考して長考して
● ioDrive の、桁違いに低い latency に着目して
● ストレージというより「ちょっと遅いメモリ」と考えて
● MySQL の buffer pool を減らし、大量の connection 張れるように、
大量のqueryを受けられるように、メモリの割り当て方を変更した
● 詳しくはこちら
まずはそこそこの容量の ioDrive

● 新しいハードウェアに対する心理的障壁として、「特性がわからない」「どん
な壊れ方をするかわからない」というものがある
● ioDrive を、ある程度まとまった台数酷使したことによって、どんなふうに
故障するのかが、つかめてきた
● ioDrive 導入以前より、 NAND Flash への心理的障壁はだいぶ取り除
かれてきたので、そろそろ次のステージに行ってもいいころ
● そうこうしていたら
ハードウェアは壊れるまで使ってナンボ

● 時は流れ、NAND Flash の価格が下がり、大容量化が進んでいった
● 800GB以上のエンタープライズ仕様のSSDが普通に買えるようになった
● これは使いたい
● 当時、容量大きいSSD使ってる他社事例それほど多くは聞かなかったので、使ってやり
たい
● いまは珍しく無いと思いますけど
● 他社が活用できてないものを活用することによって、サービスの競争力を向上させる
● SSD は random I/O 性能が高いし、15krpm の SAS HDD でRAID
組むより消費電力少ないので
● ラック単位で考えたとき、よりCPUに電力を回せるようになる
NAND Flash の価格が下がってきた

だがしかし

● SSDにリプレースしなくても動かせるDBが大量にあった
● 100-200GB程度しかないDBでは、800GBのSSDは無用の長物ではな
かろうか？
GREEは力の限り sharding していた

そこで考えた

● DBが100-200GB程度しかないなら、サービス無停止で master 統合す
ればいいってことで、サービス無停止で master 統合する方法を考えた
● DBが巨大になるとバックアップとるのに時間かかるようになるし、管理が
大変になるので、大きく運用を変えない範疇で、バックアップの取り方を変
更することにした
DB統合するしバックアップの取り方も変える

● HDDのころは、masterとslaveは146GBのHDD*4でRAID10だった
が、バックアップファイルを取得するためのslaveはHDD*6とかHDD*8
とかで、データベース用の領域と、バックアップファイルを書き出すための
領域を確保できるようにしてた
● 具体的には、 mysqld 止めて datadir を tar ball で固めてた
● つまり、masterのサーバとバックアップファイルを取るためのサーバは、
ストレージの容量が等しくなかった
かつてのバックアップの取り方

● バックアップサーバとmasterで同じ容量のSSD使うと、バックアップを取
ることができない
● DBで800GB使いきっちゃうと、 tar ball とれない
● 数TBの大容量 PCI-e SSD をバックアップサーバ用に使う？
● それはリッチすぎるコストパフォーマンスが悪い
● HDDだとI/Oの性能が追いつかない
● DBを統合するということは、それだけ更新が増えるということでもある
● SSDをRAIDコントローラで束ねる？
● そうするとRAIDコントローラがボトルネックになるケースも出てくる
● かつては、RAIDコントローラ経由だと SMARTがとれないという課題もあった
一番容量のでかいSATA SSDを使いたい

● HDDもSSDも、ブロックデバイスは、一つのI/Oコントローラに対して
read と write を同時に発行すると遅い
● read only ないし write only のときに最大のスループットがでる
● RAIDで束ねたHDD上で tar ball 取得するの、データベースが大きくな
るに連れて、無視できない遅さになってきていた
● SSDに移行したとしても、このままだといつか遅くなって困るんじゃない？
大容量のSSDを使う前から、課題意識はあった

● master/slave/バックアップサーバをぜんぶ 800GB のSSDにする
● バックアップサーバは ssh 経由で、同じラックにある SATA HDDの
RAID6なストレージサーバに tar ball を書き出す
● $ tar cvf - ${datadir} | pigz | ssh ${storage_server} “cat -
>backup.tar.gz”
● SSDなので tar するときの read は速い
● pigzでCPUのcoreぜんぶ使いきって圧縮するので、帯域制限にもなるし、
通信量もへる。まぁ、ラックをまたがないので、全力で転送しても困らない
● HDDは sequential write only になるので、書き込むのは充分速い
● 運用や監視も、既存の方法と比べて大きくは変えなくて良い
方法を変える、許容できる範囲内で

● データが巨大になると、DB再構築するのに時間がかかるようになる
● 今までN+1の構成だったところはN+2にする
● slaveは一台多めにしておく。一台故障したら、もう一台故障する前にじっくり再構築
● ストレージサーバは RAID6 にする。 SATA HDD の故障率を考慮して
● ストレージサーバはTB単位のデータを持っているため、電源などが故障したときのダメー
ジがでかいので、二台構成にする。
● バックアップサーバから書き出す先は現行系のストレージサーバにして、待機系は cron で
rsync してコピーする
● ストレージサーバは SATA HDD にしたから大容量にできたので、ストレージサーバ１台
に対して、書き込むバックアップサーバは複数台にする。それならば、ストレージサーバを
２台構成にしてもコスト的にペイする
● 最終的に、トータルで台数減ればそれでいい
破綻しないよう、考えながら集約する

図にするとこう

● Google の Warehouse-Scale Computer ほど大きい粒度ではなく、４
本以上のラックを一つの単位として考える
● replication の traffic は、これらのラックに閉じ込めてしまう。
● RAID5がパリティを複数のディスクに分散させるように、masterやバック
アップ用のサーバを複数のラックに分散させる
● 万が一、ラックごと落ちたとしても、影響を受けるmaster の数を限定的にできる
● master -> slave 間の replication の traffic が、ラックごとに偏りにくくなる
● アプリケーションサーバ <-> slave の traffic が多かったとしても、ラックごとに偏りに
くくなる
● バックアップサーバを分散配置することで、ストレージサーバのディスク使用量を、ラック
ごとに偏らせないようにする
複数のラックをグルーピングし、RAID5の様に扱う

● 現状のHWの特性や、今後のHWを想定している
● サーバのNICの帯域が増えても、これらのラックの集合の中でその性能が活かせる
● 弊社の場合、KVSの replication の traffic が大変多いのだが、 KVSやMySQLの
replication の traffic を特定のラックに集約できると、運用上楽になる
● pigz でバックアップファイルを圧縮するので、DBの集約度が上がってDBのサイズが増
えても、CPUのコアが増えれば、バックアップの取得時間を稼ぐことができる
● SSDの消費電力の少なさを活かして、一ラックあたりの集積度を上げていける
● SSDは消費電力が少なく熱にも強いから、そのぶんCPU で TurboBoost 使って、熱
出しつつ性能を引き出す方向で行ける
● TurboBoost 使うことで、NICの帯域が増えても、CPUがパケットさばけるようにする
● 現状はSATAのHDDをバックアップ用のストレージに割り当てているけど、SSD のバイ
ト単価が十分下がっていけば、別にSSD でもかまわない
このラックの使い方には、いろいろな思惑がある

おさらい
ここまで

ここからが
最近の話

● エンタープライズ仕様のSATA SSD でも、1TB超の製品が出てきた
● 3D NAND が実用化してきているので、容量は来年以降もまだまだ増え
ていく
● わたし的には、まだまだ集約していけると思う。少なくともバックアップサー
バは
● 仮に master/slave が 800GB 以下のままでも、バックアップサーバであれば、
mysqld を複数プロセス相乗りしてもそれほど困らないので
● バックアップサーバだけ、800GBより大きい SSD 積んだっていい
● 例えば、バックアップサーバに 1.6TB くらいの SSD を積んで、 mysqld を２プロセス
起動して、 800GB の SSD つんだ master 二台と replication しても良い
SSDの進化はめざましい

が

● ssh 経由で、同じラックにある SATA HDDの RAID6なストレージサーバ
に tar ball を書き出す方法、うまくいったんだけど
● SSD は書き込み寿命という概念があるので、DB のフルバックアップを定期的に SSD
へ書き込むのはあまりうれしくないが、バックアップの書き込み先がHDD なら、定期的
にフルバックアップ書き込んでも、別に困らない
● SATA HDD は 24時間365日フル稼働させると設計的にきびしい製品もあるが、daily
のバックアップ保存先として使うなら、24時間フル稼働するわけではない
● 書き込み寿命の概念があるけど高速なSSD は、お客様向けのサービスに使って、書き
込み寿命の概念がないけど安価なHDD は、バックアップの保存先に使う
● そんな具合に上手く行ったんだけど
● ストレージサーバの HDD の容量を増やして集約率を上げていくなら、見
なおして良いポイントが幾つかあるなと、実稼働させていくうちに見えてき
た
サーバの構成を見なおしてもいいころ

● ストレージサーバのCPUはスカスカなので、CPU 1socket に対して、もっ
と大容量のストレージが扱える
● バックアップサーバから書き込むとき、ストレージサーバはsshd くらいしか CPU 使わな
いのだが、 sshd １プロセスで複数のコア使えなくても、複数のバックアップサーバから書
き込んでいるので、結果的にストレージサーバのコアは複数使いこなせている
● バックアップサーバが pigz で圧縮したものをストレージサーバに書き込んでいるので、
ssh で暗号化するデータもストレージに書き込むデータも、圧縮済みで最小化できてい
る。
● そのため、ストレージサーバの CPU 負荷は低かった。
● その結果、ストレージサーバで増やしたいリソースは次のような印象
● NICの帯域 >= ストレージの容量 >>> （越えられない壁） >>> disk の書き込み負
荷 >>> CPU 使用率
ひとつひとつ、サーバ上のリソースを見直していく

● GbE 経由では 120MB/sec 程度でしか書き込めないが、いまどきの
HDD とRAIDコントローラだと、RAID6 でも 120MB/sec なんて余裕す
ぎる（HDDの本数によるでしょうが）
● RAIDコントローラをもっと酷使するためには、 GbE では全く足りないので
、10GbE 以上の帯域を用意するしかない
● NIC の帯域が太くなると、 tar ball 書き出す時間を短縮できるので、 DB
のサイズが大きくなっても運用上さしつかえないし、ストレージサーバのス
トレージの容量を増やしてもいい
少なくとも 10GbE

● 巨大すぎる RAID は、リビルドにかかる時間が長くなる
● リビルドの時間が、 HDD 一本あたりの容量と本数に比例するなら、わたしは容量を犠
牲にしようと思う
● HDD の本数が増えて消費電力増えたとしても、性能面などでのメリットがあればいい
● ラック単位で考えたとき、電力面でバランスが取れていればそれでいい
● 可能であれば、１台のサーバにRAIDコントローラを複数積みたい
● 一つのRAIDコントローラにぶら下がってる HDD の本数が減れば、リビルドの時間はそ
れだけ減らせる。なので複数積んで、管理するHDD を分散させる。
● どうせ複数のバックアップサーバから書き出すので、 RAIDコントローラごとにボリューム分か
れていても困らない
● バックグラウンドでリビルド走ってるときも、リビルド走ってない方のコントローラは、性能に影
響しないだろうし
RAIDはあまり大容量すぎても意味が無い

● ある程度まとまった本数の HDD を積めるならば、 RAID6 より RAID60
にして書き込み性能を改善させる
● HDD の特性として、円盤の外周と内周で性能差が出るケースはあるだろうから、性能に
はある程度余裕をもたせておいたほうがいい。
● 実際にファイルを書き出したり削除したりすると、必ずしも局所的なアクセスになるとは限らな
いだろうし
● NIC の帯域に対してある程度余裕を持たせておいて、あくまでも「ボトル
ネックは NIC の帯域」となるようにしておいたほうが、運用がシンプルに
なって良い
● NIC に合わせて設計するときに難しい点は、NIC の帯域が1.5倍くらいのペースで増
えるのではなく、 GbE から 10GbE など、いきなり倍以上になってしまうところ。
RAID6 より RAID6+0

● いくらバックアップファイルを保存するストレージサーバとはいえ、一台に集
約してしまったら、（直接サービスに影響がでないとしても）故障などの障害
発生時、復旧のための運用上のコストは、かなりきびしいものになる
● 複数のラックに分散配置して、万が一のときでも、復旧作業の作業コスト
が、許容できる範囲に収まったほうが良い
● 消費電力高いパーツを大量に積んだサーバを、一つのラックに集中して配
置してしまうと、突入電力の面でも懸念が残る
程よい大きさのストレージを、分散配置するのがよい

● ストレージサーバに 10GbE を積んでも、ストレージサーバにバックアップ
書きだすサーバが同じラック内にいるだけなら、バックアップのためのトラ
フィックは、上流のコアスイッチを経由しない
● 仮に、 GbE を積んだ10台のバックアップサーバと、 10GbE のストレー
ジサーバが全力で通信して 10Gbps 目一杯使うとしても、その通信が
ラック内で完結しているなら、ネットワーク機器の設備投資は、局所的なも
ので済ませられる
● そのようなバックアップサーバとストレージサーバのセットが複数のラックに
分散配置できていれば、大容量のバックアップを高速に取得できる
● もし、オンプレミス環境からクラウドストレージにバックアップを書き出すとし
たら、このようにネットワークの帯域を使うことは、コスト面で難しいだろう
トラフィックがラックの中で完結するメリット

● ストレージサーバ１台に毎日書き出したいバックアップの総量は、何TBな
のか？それを何時間で書き込みたいのか？
● 時間的に GbE の帯域で足りるのか？足りないなら、 10GbE の帯域に
見合うだけの書き込み性能を、RAIDコントローラは持っているのか？
● バックアップは何日分保存しておきたいのか？それだけの容量を保存する
とき、 RAID のリビルドはどれくらいかかるのか？ストレージサーバの再
構築にかかる時間はどれくらいか？
● RAID のリビルドにかかる時間を短縮したいなら、RAIDコントローラはいく
つ積むべきなのか？
● 最終的に、電力や設置スペースなども踏まえて、 HDD で RAID を組む
コストメリットはあるのか？
一つ一つ、積み上げて見積もる

● リビルドにかかる時間などは看過できないけど、実運用に収まる規模であ
れば、未だに RAID はコストパフォーマンス悪くない仕組み
● ある程度の規模になると、分散ファイルシステムなどを検討しなければなら
ないだろうけど。障害発生時の復旧コストや、ネットワーク機器への設備投
資など考えると、 RAID を使ったストレージサーバや、同一ラック内からそ
のストレージサーバに Ethernet 経由でバックアップを書き出すというの
は、現時点では充分選択肢になりうる
● 保存するデータの規模や用途、障害復旧の方法、運用コスト等考慮し、自
分たちにとって適切な方法を選んでいくのがよい。
● その一つとして、 RAID はまだ選択肢になりうると思う
要素技術としてみたときの RAID

● 1TB超のエンタープライズ向け SATA SSD、 10GbE 、そういったものに
対して
● 2Uくらいのストレージ特化型サーバがあれば、 RAID で 3.5inch SATA
HDD を束ねて、ある程度コストパフォーマンスのいいバックアップシステ
ムが設計できる
● 例えば、 HPE Apollo 4200 のような2Uのサーバ使うとか
● Hadoop 以外でも、ストレージ特化型のサーバって意外と使い道あると思
います。容量100TBとかなくてもいいんです。HDDたくさん積めれば、使
い道はあるんです。 SSD 積んだサーバの、補助記憶装置的に捉えれば
いいんです。
現時点でのハードウェアを見渡すと

このへんまでは
取り組んでる

で

● その一方、パブリッククラウドも活用してるし気にしてます。
● 仮想化というレイヤーを挟まないことによって、MySQL からハードウェアまでの間を構
成する要素が減るので、何かあったときに調査しやすいのですが
● パブリッククラウドのメリットも当然有るので、そのへんはいろいろ比較しながら勉強させ
てもらってます。
● 余談ですが、パブリッククラウドでも、Linux の kernel や TCP に関することについて
は、やはりチューニングすべきポイントがあって、そういった意味では、オンプレミス環境
でもパブリッククラウドでも役に立つ知識や経験があります。
● TCP や Linux の kernel に関する知識は、インフラエンジニアである限り、当分役に立
つもんだと思います。
パブリッククラウドをチラチラみつつ

わりと真面目に
比較している
ところは

● （月並みですが）Googleはすごいと思ってます。何がすごいかというと消
費電力効率です。彼らのデータセンターのPUEはハンパないです
● Googleに限らないですが、パブリッククラウド事業者は、日本以外の、一
つのラックに電力を大量に供給できて、一つのラックにサーバをたくさん詰
める地域でもサービスしてたりします。
● そうすると、日本より空間効率良くなって集約度が上がっていくわけで、日
本よりインスタンス費用が安くなっていきます。
● 極論すると、アメリカ西海岸の方が、パブリッククラウドのインスタンス安い
なら、アメリカ西海岸でサービス開発してる人、コスト面で超有利じゃん？と
思うわけです
● インスタンスの安い地域と比べて、日本の中でどうやってコストを最適化し
ていくか？という課題が常にあると思っています
消費電力効率と空間効率をいかに最適化するか

● 日本では、スパコンを設置するためのデータセンターを設置する場合、場
所選びが大変なのではないか？と思います。
● 一方、土地が広い国は、データセンターいくつも作ってスパコンたくさん開
発できる余地があるんじゃないでしょうか？
● スパコンはとても電力使うので、消費電力の多いデータセンターをいくつも
設置できるということは、電力効率が良いデータセンターのためのノウハウ
が、その地域に蓄積されていくということになるのかもしれません。
● TOP500の国々を見ていると、そんな気がしてきます。
これは非常に個人的な推測なんですが

● 日本はGreen500で健闘してますが、いかにして電力効率を最適化して
いくかっていうのが、日本の土地のことを考えると、方向性としては正しい
んじゃないかなという気がします。
● 消費電力多いけどclockの高いCPU使いたいなら、パブリッククラウドで、
電気たくさん使える地域でインスタンス立てる方が、今後、どんどんコスト
パフォーマンス良くなっていくんじゃないかという気がします。
● そんな中、日本のデータセンターにあるサーバを使いたいなら、いかにして
電力効率を最適化し、ランニングコストを削減していくかが、重要なポイント
ではないかなと考えています。
スパコンの世界を眺めて思うのは

そう思いながら
サーバいじってて
気がついた

そうだ

CPUのCoreを
disable に
しよう

● GREEのサービスはCPUが4Coreくらいの時代から続いてるので、CPUの
Coreが10とか20とかなくても、どうにかなるケースが多い。
● DBはCPUよりもSSDとメモリ。もしCPU使用率高いなら、最適化を試みればいい。
● しかし、ワーストケースとして「すべてのCoreがぶん回されたときの消費電
力」を想定して、ラックに積むサーバの台数を決めなければならない
● そうであるならば、BIOSから使うCoreの数を制限して、CPUの消費電力
の上限を設けてしまえばいい
● Core数の少ない Low-Core-Count のCPUであれば、使うCoreが少な
いと、 TurboBoost でより高いClockに引き上げることも可能になる
● MySQL5.6以前であれば、SQL_Thread がシングルスレッドなので、シングルスレッド
性能高いほうが Replication では有利になる
MySQLを最適化してくと、そこまでCPU使わない

MySQL最適化して
使うCoreの数を制限して
消費電力を削減し
お客様に還元する

● 1Uではなく、 2U4nodeなどの高集約型のサーバをDBに使う
● master/slaveは複数のラックに分散する設計にできているので、最悪、サーバごと落ち
て4node全滅したとしても、影響範囲は限定的にできる。
● BIOSからCPUのCore数を制限して、消費電力を引き下げつつ、
TurboBoostでより高い clock を、より高いシングルスレッド性能を狙う
● 1nodeあたり1U未満のサーバであれば、一ラックあたり46Uしかなくて
も、１ラックあたり 48node くらいを狙える気がしている
● ざっくり考えて、１UでDB一台130Wくらいだったけど、110Wくらいを狙えるのでは
● 低電圧版のCPU１個で50-60W程度
● DDR4のメモリ１枚が9-10W程度で（クアッドチャネルということでそれが４枚）
● SATAのSSDとNICがそれぞれ5-6Wずつ
● ファンや残りのパーツで 10Wくらい余裕みて
● 電源の力率をざっくり 0.9くらいで考えると
● このままだとサーバ１台で 130Wくらいだが、Core を disable してそれを削る。
今後、検討したいこと

こんな感じで

48portのswtich、
１ラック分のサーバで
ポート使い切ってやろう

● 10GbEのストレージサーバを組んだことで、バックアップサーバ用のラック
は実績が上がってきた。
● Webアプリケーションサーバ専用ラックとDBサーバ専用ラックを、それらと
切り離して、上手く組んで行ければいいかなと思っている
● アプリケーションサーバとDBサーバで専用ラックを別々に組めると、アプリケーション
サーバとDBサーバの台数比率を自由にコントロールできるので、柔軟に台数構成を考え
られる。
● アプリケーションサーバはCoreたくさんあったほうが集約率上がるので、
Core を Disable にすることはあまり考えてないが、DBはCoreを
Disable にすることで、１ラックあたりの集約度を上げていければいいかな
と思ってる
● 最大で、 1ラック48port 使い切れる範囲内まで disable にするということで
バックアップ用HDDは他のラックに確保できたので

現時点では、
ある程度までは
電力効率を
改善できそうだ

● おそらくきっと、サーバにも 40Gbps のネットワークインターフェースが普
及してくる時代になってくるだろうから
● 参考： EthernetやCPUなどの話
● 40GbE などが普及する時代になってくると、これらのバランスがまた崩れ
てしまう
● いまは仮想化しないで localhost 上のSSDを使ってる。ネットワーク経由で disk にア
クセスしないで済ませられているので、データセンター内のトラフィックを絞れている。将
来、広帯域のネットワークが充分安価になれば、localhost 上のSSDを使わない方が、
最終的にランニングコスト下げられるのかもしれない。
● おそらく2020年代には、別の選択肢を考えなければならない
● なので、次はどうしようかと、個人的にいろいろ考えてるところです
次の、2020年代には

おわり

MySQLやSSDとかの話　その後

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a MySQLやSSDとかの話　その後

Similar a MySQLやSSDとかの話　その後 (20)

Último

Último (11)