技術めもIT系のめもを蓄積していこうかとアーカイブ「2016年05月」GCPとAWSの拠点間通信速度GCPとAWSで、拠点(リージョン)間の通信速度を簡単に図ってみた。正確ではないし、3回程度しか実施していないので、その点は考慮ください。■EC2のインスタンス(TOKYO)から(AMERICA東部)への230MBのSCP23秒ほとんど同じ。GCPはネットワークの強さをうたっているが、AWSと変わらないケースもある。GCPの場合、ローカルネットワーク上で、異なるリージョンのインスタンスをまとめられるので、データベースなどを複数リージョンで準同期レプリケーションできるとよいと思っていたが、その目論見は成立しそうにないことがわかった。実際にサービスとしてユーザの体感速度的なものは、広域範囲で考えればAWSより優秀なのではないか。Storage(以下、GCS)がすごい。AWSでいうところのS3にあたるものですが、バケット間同期が、25,000ファイル、8GBを転送(同期)するのに、約5分。JAVAの並列処理(4CORE)で、S3に同じ量をアップするのに、8分だったから、ちょっと負けた気分。GCSはgsutilというツールを使うのがよい。JAVAなどはSDKが出ているが、とてもめんどくさい。サービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。追記ちなみに、上記の5分という数字は、バケットのリージョンが異なっていても、同じでも変わらない。非同期レプリケーション準同期レプリケーションがあることが抜けていた。promotionを使う場合、データロスト率が低い準同期方式がよいと思われる。準同期レプリケーションについては、詳細説明をされているホームページがあるので、それを参照されたい。準同期レプリケーションの設定は以下。準同期レプリケーションの設定が入る。ここでは、masterがslaveに、slaveがmasterになることがあるので、master・slave問わず同じ設定を入れている。ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。遠隔地にバックアップをおくこともできないと思われる。これらについて、検証したら詳細を記述したい。詳細はさておき、先に結論を書いておく。【前提】maxscaleによるWriterReaderSplit機能を使うmasterダウン時には、生きているslaveが自動昇格する【結論】ノード数は3以上が推奨と書かれているが、ノード数が1になると、maxscaleのWriterReaderSplitが機能しなくなるslaveの同期が失敗していている状態では、masterに昇格しないし、maxscaleのクラスターからも外れるということが挙げられる。3ノードあっても、2ノード死んだら、実質アウトなのである。そのため、打っておく手段としては、masterがダウン→手動復旧→自動で新masterのslaveとなるようにする1ノードになった場合、maxscale経由でアクセスしないようにするということをやっておけば完璧だと思われる。ちなみに、良い点として、masterがダウン→復旧しても、新masterとバイナリログポジションがずれているため、maxsacle上のクラスターからは外され、マルチマスター状態にはならない。上記対策もなんとか実現できそうな気がしている。そのあたりの検証記事を、今後書こうと思います。[コメントがあればどうぞ]MariaDBクラスター~その1MariaDBでクラスターを組む際、maxscalemariadb-replication-managerMariaDBを使うとよい。promotion(マスタースレーブ、データ同期型)のような3つの手段があるが(もっとあるかも。repliacation-managerの監視および発砲でいける。promotionの特徴を書いてみる。使いどころはサービスに依存するのかもしれない。promotionがよいと思う。決め手は、更新速度とロックの有無かと。promotionと組み合わせないとデータロストしちゃうかも。promotionについて、maxscaleとreplication-managerを用いた構成の説明(やってみた)を近々で書こうと思う。Evanescence.。