UD Day 18 アーキテクチャーの検討13(その他の基盤的な検討事項:主にCassandra)

アーキテクチャーの検討としては、前回12までの分で全て(要件定義フェーズ)ですが、以下にその他諸々で調査した内容について記載します(走り書きの類です)。以上です(続く)

・GKEはDocker?実績はどうか?
 GKE はdockerベース。実環境で確認済み。web/ap層は冗長化で可用性は確保できると判断。実績はまあまあ(心配する声があるのも事実)。Data層は??
 k8sのData層としての利用は否定的な見解(Netflix)

・Cassandraで暗号化はできるか
 商用以外は見つからない。アプリ側でSensitive Dataのみ暗号化する
 (例えば、暗号化方式を複数持ちデータのはじめ1文字(数bit)で暗号化方式を指定する(一見するとどう暗号化してるのかわからない)

・CassandraはインメモリーDB(redis, memcachedなど)と併用しなくていいのか
 Netflixのテックblogに詳細なレポートあり。結論的には、SSDベース  Cassandraがあれば、インメモリーDBなしにできる(AWSの例だが、GCPの方が、SSDはパフォーマンスが良い印象がある。別記事にて)。
 レポートの結論としてはより少ないSSDベースのノードで置き換えれる(コスト安くなる)かつlatencyがより少なくなるとしている。
  

・CassandraなどのDBをk8sのStatefulSetで運用するのは問題あるか
k8s on 2 GCE nodes vs 3 GCE nodes
Defenitive Guideでは、Dockerの利用は非推奨。(Dockerでパフォーマンス上問題となり得るのがネットワークとデータディレクトリーでソフトウェアルーティングが用いられている点。Cassandraの場合、50%程度の低減となりえる)

 ・(関連)DockerとVMのパフォーマンス比較をするとどうなるか
  DockerはNativeよりやや劣る程度という記載 
  CPU, NW, IOの単位で計測結果を記載。P21の理論値はローカル内だから気にしなくて良いかと思う。Port-forwardingかdedicated IPのどちらかは気にした方が良さそう。(GKEの場合は?Docker-to-docker(orVM)をテストした方が良いかも。)

・Cassandraをmulti-DCでdeploy可能か
 可能だが、Readのlatencyについて懸念あり。実環境で2ケースを試すべき(Single-AZ and multi-AZ:前者同じAZに3つ、後者2-3つのAZに6つ )。
 latencyはAZ(zone)間のNWパフォーマンスに依存。Multi-AZ構成にする場合の考察はこの記事が参考になる。
 一つの構成例:3つのAZ、各AZに2つのノード。RF=3として、AZ1〜3のそれぞれに同じレコードがある。一つのAZが死んでも大丈夫。
 NW帯域は別ゾーン(同一リージョン)は、同一ゾーン内でどう異なるか(以下のリンクより)同一Zone: 2Gbps/コア別Zone: 1.5〜2Gbps/インスタンスとなりそう。
 方針:上記の2ケース(同一ゾーンor同一リージョン異なるゾーン)をデータを入れた状態で試し、レイテンシーがどのくらい異なるかを実際に確認するのが良さそう。
      同一ゾーンしか選択肢としてないとなった場合には、アウテージの際のユーザ通知を考える形とすべき。
  GCPのblogによれば、2Gbps/コア、max 16Gbps/インスタンスみたい。
  Netflixでは、multi-regionのCassandraを運用してるみたい。
  ちなみにEC2の計測結果は以下(同一zone内)。最新だとでかいやつはmax25Gbps。
  2014のデータだが、計測結果(AZ間もある)がある。AZ間はAZ内より落ちる(程度はAWS, GCPで異なる)
 => Multi-AZは最小で3つのAZ、各AZに1つづ、RF=3であるが、このケースでは単に冗長性を持っているだけで、まだ分散DBの意味は持たない。増やすにはAZあたり3つづつとなる。
   また、Multi-AZの場合、AZを2つとするのには意味がない(Quorumが失敗する)。そう考えると、AZ=3が正しい。以上から、初期の段階では、マルチAZの構成は取らないものとする。

Cassandraの冗長性: replication-factorの設定値次第:node=3なら3、node=4以上なら、3〜ノード数以下という推奨例

・Cassandraの場合のテーブル設計
 RDBと異なり、クエリー毎にテーブルを作成するという方針でテーブル設計をするのが一般的(Datastax社ガイド)
  「データがCassandraに格納される順序がデータの取得のしやすさと速度に大きく影響する場合がある」(amebaのtech blogはこれでいうとダメな例かもしれない)
 運用後にデータが特定のノードに偏るなどの事象が発生(設計時に分散を考慮してやるべきだと思うが・・・)
 Cassandraのデータモデルは、KeySpace(Database)-ColumnFamily(Table)-Key(PrimaryKey??)-SuperColumn(data)-Column(data) となっている。
 Cassandraでの実際の設計例を記載(2009年に書かれたものなので少し昔なのが気になるが)
 英書を読むのが一番よさそう。

・Cassandraの実運用における問題点は?
 排他制御、削除周りの難しさが記載されている。この点は現バージョンでの詳細な調査が必要かも。あと、テスト。
 クラスタあたりのノード数の限界(1000程度)、ノードあたりの容量(3.xなら1TB程度)などの有用情報、一貫性問題についての言及


技術関連のリンク)
FBで使われている技術(かなり網羅的)
FBで使っている技術(2011年の資料だが参考になる)。HayStackで画像の管理をしている(保存・取り出し)のは参考にすべきかもしれない。初めはBlobで作って、どっかでHayStackに移行するとか。
画像関連。 回答が秀逸。Generalなやり方や考え方に言及している。RDBだとボトルネックにもなりえるし、BLOBを扱うのは微妙かもしれない。
FB Haystack使用
Swift -> S3に画像を保存する。
MySQLの分散。Group Replicationがやりたいことを満たすソリューション。Master、Read replicaでも良いが、当初考えてたテーブル分割は意味が低減するか?
上のblogに記載のMySQLの分散方法まとめ。正直、テーブル分割(分散DB的)を想定した場合に使えるものはないかも。
MySQLのCharacter set(encoding)。選択肢としては、cp932(日本語)が良さそう。
GCEでSSDを使う(やり方の参考にとてもなるので、実装時に見るべき!)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です