Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Apache Cassandra on AWS

oranie
October 11, 2017

Apache Cassandra on AWS

https://d0.awsstatic.com/whitepapers/Cassandra_on_AWS.pdf
Whitepaperの日本語解説セッションで使ったスライドです。

oranie

October 11, 2017
Tweet

More Decks by oranie

Other Decks in Technology

Transcript

  1. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Amazon Web Services Japan 株式会社 Takashi Narita Apache Cassandra on AWS
  2. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. ⾃⼰紹介 成⽥ 俊(id:oranie、@oranie) Amazon Web Servies Japan 株式会社所属 ソリューション・アーキテクト Cassandra summit JP 2014 speaker Session title: 100 node cluster admin operation
  3. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 本セッションについて White paperをベースに各章、項⽬の紹介・解説をします。 CassandraやAWSの各サービス⾃体の解説はあくまでも 簡単に、AWS環境で重要となるポイントについて紹介・解 説を⾏いますので、Cassandraのベースとなる知識につい てはある程度理解しており、AWS環境でのクラスタ構築を ⾏う⽅などが対象となります。
  4. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 免責 本スライド内の内容については、White Paperの内容解説 以外の意⾒などはあくまでも個⼈の経験に基づくもので所 属する組織を代表する意⾒ではありません。
  5. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 「Apache Cassandra on AWS」について AWSはwhite paperとして 様々な情報を公開しており、 OSSプロダクト運⽤に役⽴つ ドキュメントも出しています。 Cassandra運⽤全般的に使え る情報、AWS特有でケアすべ き内容など様々な情報を網羅。 http://bit.ly/2wwdWa7
  6. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 「Apache Cassandra on AWS」について Introduction NoSQL on AWS Cassandra: A Brief Introduction • Cassandra: Key Terms and Concepts • Write Request Flow • Compaction • Read Request Flow Cassandra: Resource Requirements • Storage and IO Requirements • Network Requirements • Memory Requirements • CPU Requirements Planning Cassandra Clusters on AWS • Planning Regions and Availability Zones • Planning an Amazon Virtual Private Cloud • Planning Elastic Network Interfaces • Planning High-Performance Storage Options • Planning Instance Types Based on Storage Needs Deploying Cassandra on AWS • Setting Up High Availability • Automating This Setup • Monitoring by Using Amazon CloudWatch • Using Multi-Region Clusters • Performing Backups
  7. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 「Apache Cassandra on AWS」について Migration into AWS Analytics on Cassandra with Amazon EMR Optimizing Data Transfer Costs Benchmarking Cassandra Using the Cassandra Quick Start Deployment
  8. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Introduction 主要なNoSQLデータストアについて説明 Key-value stores: データはkey-valueの構造で持ちprimary keyに対してクエリを投げる. 基本的に ⾏単位でデータを管理. 例としてCassandraやAmazon DynamoDBなど Graph databases: グラフ構造でデータを管理出来る. 例としてTitanやNeo4jなど Document databases: データはドキュメント形式 (for example, JSON files) で格納されドキュメ ント内のフィールドにアクセスが可能.例としてMongoDBやAmazon DynamoDBなど Columnar databases: ⾏単位では無く列志向でデータを管理. 例としてHBaseなど
  9. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. NoSQL on AWS AWS上ではフルマネージドサービスでデータストアを利⽤することも出来、 要件に合わせてOSSプロダクトを⾃分で構築・運⽤する事も可能です。 ここでは代表的な例としてフルマネージドサービスではNoSQLデータストア としてDynamoDB、オブジェクトストレージとしてS3がどのような特徴を持 ち、⾼可⽤性とスケーラビリティを提供出来ることを説明。
  10. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Cassandra: A Brief Introduction Cassandraの基礎的な知識について • Cassandra: Key Terms and Concepts • Write Request Flow • Compaction • Read Request Flow どのようなコンポーネントで構成されているのか、どのようなフローで処理が ⾏われるかなどを解説しており、まずどんなデータストアなのかを知りたい⼈ にもオススメ。
  11. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Cassandra: Key Terms and Concepts Cassandraで重要となる各要素について • クラスタ • 可⽤性を担保するための分散の考え • ノード • commit log • memtable • sstable • bloomfilter • index file • key spaces • table これらの概念についてそれぞれ解説。特にAWS環境では可⽤性担保の所でAvailability Zoneという 考えと合わせて設計する必要があることを解説している。
  12. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Write Request Flow 書き込み処理の流れについて Cassandraはどのような流れでデー タが書き込まれるのかをノード間の 流れとノード内の流れや、ノード障 害が起こった場合にhinted handoff などの仕組みでカバーしているなど も解説している。 ※引⽤している右の図の3と4は記載 ミスで逆になっています。
  13. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Compaction Comapctionについて まずComapctionがなぜ⾏われるのか、どのような仕組みで⾏われるのかを解 説しており、Cassandra運⽤では⾮常に重要な要素となるため是⾮抑えて欲し い項⽬。 特にノードの選定などでDisk I/Oが重視される場合はこの処理が⼤きな割合を 占めます。
  14. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Read Request Flow 読み込み処理の流れについて 書き込み処理と同様にCassandraは どのような流れでデータが書き込ま れるのかをノード間の流れとノード 内の流れを解説。
  15. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Cassandra: Resource Requirements Cassadraクラスタを構成するノードにおいてどのようなリソースを重視すべ きなのか • Storage and IO Requirements • Network Requirements • Memory Requirements • CPU Requirements の項⽬毎にどのような注意点があるのか。
  16. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Storage and IO Requirements 書き込みフロー、読み込みフロー、Compactionなどでも解説したとおり、 ワークロードに応じてDisk IOは⾮常に重要な要素となります。 書き込みでは主にシーケンシャルライトが重要ですが、読み込みワークロード などに応じてランダムリードも重要になるため、基本はSSDベースが推奨。 ファイルシステムはXFSを推奨しており、ext4やext3はパフォーマンスの観 点から⾮推奨。 AWS環境ではEBSを利⽤するのかインスタンスストアを利⽤するのかの選択 肢があり、後の項⽬で細かく説明。
  17. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Network Requirements Cassandraはアーキテクチャの特性から⾮常に多くのNW処理が発⽣するため どのような処理でNWリソースが利⽤されるのか。 単純にクライアントからのクエリの処理だけではなく、Gossipによる各ノー ド間のやりとりやrepairなどの多くのデータのやりとりが発⽣するため、ここ では最低でも1Gbpsは利⽤できるインスタンスを利⽤する事を推奨しています。 AWS環境では更にNW最適化オプションが利⽤出来るインスタンスを推奨して おり。
  18. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Memory Requirements CassandraはJVM上で動くアプリケーションの為、どのようなメモリ設定が必 要か。 • MAX_HEAP_SIZE • HEAP_NEW_SIZE の設定割合やheap領域以外にもOSのページキャッシュがパフォーマンスに影 響する為、プロダクションレベルでは最低でも32GB以上のメモリが利⽤出来 るインスタンスを推奨。但し2.1ベースでの解説なので、最新のパラメータな どはDatastaxのドキュメントを確認。 https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/op sTuneJVM.html
  19. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. CPU Requirements CassandraはCPUバインドな処理が⾮常に多い事と、そのアーキテクチャから 多くのCPUコアがあるマシンは有効に利⽤出来る。 AWS環境で書き込みが多い場合は最低でもvCPUが4個以上あるインスタンス を選択する事をここでは推奨。但しあくまでも初めの選定の⽬安で、必ずワー クロードテストをして最終決定を。
  20. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. リソース関連のまとめ Cassadraはそのアーキテクチャからスタンドアローンなデータストアと⽐較 するとDisk IO、NW、メモリ、CPUそれぞれにある程度のスペックが求めら れます。 また、個⼈的には⼩さなインスタンスを並べるよりもある程度のスペックを 持ったインスタンスでクラスタのノード数を抑える⽅が管理コストの観点など からも良いと考えます。 次の章からは実際にAWS上で設計をする上での解説になります。
  21. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Cassandra Clusters on AWS 実際にAWS上でクラスタを設計する上で重要となる要素として • Planning Regions and Availability Zones • Planning an Amazon Virtual Private Cloud • Planning Elastic Network Interfaces • Planning High-Performance Storage Options • Planning Instance Types Based on Storage Needs という項⽬毎にどのような注意点が必要か
  22. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Regions and Availability Zones この項⽬ではまずリージョン、AZについて説明。 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-regions-availability- zones.html
  23. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Regions and Availability Zones この構成をベースにCassandraでは Ec2Snitch Ec2MultiRegionSnitch の2つのSnitchが⽤意されている。こ れを使うと起動したノードがどこに いるかを判定し⾃動的にDCやrackな どを設定してくれる。 引⽤: https://docs.datastax.com/en/cassandra/latest/cas sandra/architecture/archSnitchEC2MultiRegion.htm l
  24. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Regions and Availability Zones
  25. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Regions and Availability Zones これらを元によりグローバルに利⽤する想定であったり、⾼可⽤性などを求め るならマルチリージョン構成のCassandraを検討する。単⼀リージョンで⽤途 が問題無ければ単⼀リージョン構成での設計をする。 マルチリージョンになった場合はkeyspaceの設定でどのDCにどれだけのレプ リカを持つかを設定し、クエリを投げる際にEACH_QUORUMや LOCAL_QUORUMなどでレイテンシとデータの堅牢性をコントロールする事 が重要。
  26. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning an Amazon Virtual Private Cloud AWS上で構築する際にVPCに関連する点について。 VPC内にサブネットという単位でNWセグメントを設定するが、どういった点 に気をつけるかにも⾔及。 また、VPC内にEC2インスタンスを起動しCassandraクラスタ⽤のノードを⽤ 意する構成を説明しており、その中でもパフォーマンスに影響する ・インスタンスファミリー ・Hardware virtual machine (HVM) AMI ・拡張ネットワーキング ・SR-IOV Driver について紹介。
  27. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 東京リージョン Amazon Virtual Private Cloud (VPC) 特徴 (http://aws.amazon.com/jp/vpc/) • AWS上にプライベートネットワークを構築 • AWSと既存環境のハイブリッド構成を実現 • きめ細かいネットワーク設定が可能 価格体系 (http://aws.amazon.com/jp/vpc/pricing/) • VPCの利⽤は無料 • VPNは1時間あたり$0.048/VPN接続(東京リージョン) 仮想プライベートクラウドサービス VPC ( 172.16.0.0/16) 既存システム プライベート サブネット パブリック サブネット インターネット VPN or 専⽤線 ネットワークを 要件に応じて設定 インターネット ゲートウェイ
  28. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning an Amazon Virtual Private Cloud これを踏まえ、もしレプリカファクター3だった場合は3つのサブネットを全 て異なるAZに設定し、それぞれにノードを置く事でAZレベルの障害が発⽣し た場合でも可⽤性を担保出来る例を記載。 また、SSHログインする場合の踏み台サーバをどう設置するのか、EC2- Classic環境で既にCassandraクラスタが動いている場合にはVPCで提供され ている機能メリットが⾼いため移⾏を強く推奨している。
  29. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Elastic Network Interfaces ここではノードとして利⽤するEC2におけるElastic Network Interface (ENI)について解説。ENIの特徴としては以下の通りで凄く簡単に⾔うと NICの追加が簡単に可能。 • プライマリプライベート IPv4 アドレス • 1 つ以上のセカンダリプライベート IPv4 アドレス • プライベート IPv4 アドレスごとに 1 つの Elastic IP アドレス (IPv4) • 1 つのパブリック IPv4 アドレス • 1 つ以上の IPv6 アドレス • 1 つ以上のセキュリティグループ • MAC アドレス • 送信元/送信先チェックフラグ http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html
  30. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Elastic Network Interfaces ENIを利⽤する利点としては、cassandra.yamlにseed nodeのリストを記述 しなければいけないがここではIPアドレスを指定する必要があり、もしnode 障害が置きた時に⼤きなクラスタほどその変更対応が困難となる。 この時にENIに設定しているIPを記述しておくことで⼊れ替えるノードから ENIをデタッチし新たなノードにアタッチすれば、容易にIPを引き継いだノー ド変更が出来る事例を記述している。
  31. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning High-Performance Storage Options Cassandra運⽤時に求められるストレージ性能をどのように選定すべきか まず知っておきたい点としてAWSでは • Amazon EBS • Amazon EC2 instance stores の2つが選択出来る
  32. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning High-Performance Storage Options Amazon EBS Amazon Elastic Block Store (Amazon EBS) は、AWS クラウド内 で Amazon EC2 インスタンスと組み合わせて使⽤できる、永続的なブロック ストレージボリュームです。コンポーネントに障害が発⽣した場合でも⾼い可 ⽤性と耐久性を維持できるように、Amazon EBS の各ボリュームはアベイラ ビリティーゾーン内で⾃動的にレプリケートされます。Amazon EBS ボ リュームは、作業負荷の実⾏に必要な安定した低レイテンシーのパフォーマン スを提供します。 https://aws.amazon.com/jp/ebs/
  33. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning High-Performance Storage Options Amazon EC2 instance stores. インスタンスストアは、インスタンス⽤のブロックレベルの⼀時ストレージを 提供します。このストレージは、ホストコンピュータに物理的にアタッチされ たディスク上にあります。インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の⼀時コンテンツなど) の⼀時ストレージに最適です。また、インスタンスのフリート全体でレプリ ケートされるデータ (負荷分散されたウェブサーバープールなど) にも適して います。 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Instanc eStorage.html
  34. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning High-Performance Storage Options 簡単な違いをまとめると • インスタンスタイプに応じて追加コスト無しで揮発性のインスタンススト アが利⽤出来る。NVMe SSDなどが利⽤出来るので⾼I/O処理が可能。 • 実態はEC2の物理ホストのローカルディスクなので、stop/startにより仮想 マシンが別ホストに移動するとデータが消去される • EBSは永続化ストレージなので、OS領域やDBのデータなど永続化が必要な データの置き場所としてはEBSを利⽤する。 • 但しどのEBSを利⽤するか、サイズに応じてDisk I/Oやスループットが異 なる
  35. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning High-Performance Storage Options それぞれの特徴を踏まえ、EBSではどのようなオプションがあり、どれが Cassandraに向いているのか,ノード内で書き込むデータに応じて分利⽤領域 を分割するパターンなどを説明。 Amazon EC2 Instance Stores についても特徴を説明しEBSとの違いを踏ま えて、どのようなユースケースにマッチするのか、利⽤する上での注意点を解 説している。 基本的にはまずEBSを利⽤していきその上でどうしてもとなったらAmazon EC2 Instance Stores を利⽤するフローが推奨。 もちろん⾃分の要件に合致するのか検証をした上でストレージは選定を。
  36. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Instance Types Based on Storage Needs ある負荷シナリオにもとづきどのようにサイジングするかを解説。単純に IOPSやスループットでは無く、Cassandraでどのようなデータを扱いどのく らいのオペレーションが発⽣するかでどのように計算をするのかというのが解 説されているので、⾮常にサイジングに役⽴つ解説となっている。
  37. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Instance Types Based on Storage Needs 1つのノード性能限界が超えた場合はCassandraはノードを追加する事でクラ スタ内でスケールさせる事が出来るので、そこも含めてプランニングをすべき ということを推奨。 個⼈の経験からも厳密な1ノード当たりの性能測定を実施しても実際のワーク ロードとの違いや仕様変更などで要求要件が変わってしまう事が⼤いにあるの で、あくまでも1ノードの性能とクラスタの性能、クラスタの分割などの戦略 はセットで考えた⽅が良い。 そのためにもモニタリングは⾮常に重要と考えているので、単純なOSメトリ クスだけでなく各種最新のCassandraモニタリングサービスなどは利⽤を検討 したほうが良い。
  38. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Planning Instance Types Based on Storage Needs
  39. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Deploying Cassandra on AWS 前章で説明した各要素をもとに、実際にCassandraクラスタを構築するに辺り 実践的な構築パターンを記述している。 • Setting Up High Availability • Automating This Setup • Setting Up for Security • Monitoring by Using Amazon CloudWatch • Using Multi-Region Clusters • Performing Backups • Building Custom AMIs 各項⽬でAWSサービスを利⽤する事でどのように実現するかを解説。
  40. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Setting Up High Availability どのようにCassandraクラスタを⾼可⽤性を実現した構築にするか
  41. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Setting Up High Availability 抑えるポイントとしてはどのようなネットワーク設計をするのか、各ノードをVPC内にどのように配 置するのか、運⽤上必要とされるData Node以外のインスタンスはどこに置くべきなのかなどと、 Consistency Modelsの特徴と合わせて理解が出来るように解説している。 リージョン毎にAZの数が違う為、東京リージョンでは現在AZが2つなので、もし⾼可⽤性を追求す るのであれば • 3AZ利⽤出来るリージョンでの構築を検討する • 東京リージョン内のAZ毎にDCを作成し、擬似的にマルチリージョンと同じ形で利⽤出来るよう に設計を⾏う • 東京リージョンと他のリージョンでマルチリージョン構成を組む などが選択肢となる。
  42. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Automating This Setup この項⽬では運⽤⾯でAWSの機能であるAuto Scaling、NAT Gatewayを利⽤ する事で⾃動化について解説。
  43. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Automating This Setup Auto Scalingを利⽤することでノード障害からの⾃動復旧するなどの⽅法を解 説。 特にseedノードとそれ以外のノードでAuto Scaling groupを分けて、それぞ れで異なる処理を⾏わせたりする⼿法や、opscenterなどの様にMaster-Slave 的な関係のノードの場合にElastic IP addressを利⽤することでアクセス⾯で の可⽤性向上の⼿法などを解説している。
  44. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Setting Up for Security セキュリティを意識した設定につい て。 • KMS • EBS encryption • Securely Connect to Linux Instances Running in a Private Amazon VPC(blog) • Security Groupでのネットワーク 許可例 などを利⽤することで、どのように セキュアなCassandraクラスタ構築 を実現するか。
  45. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Monitoring by Using Amazon CloudWatch Amazon CloudWatchを利⽤することでどのようなメトリクスが取得でき、メ トリクス内の値が閾値を超えたらアラームを発動させる、などの監視について 単純にOSレイヤのメトリクスやCassandra関連の値をjmxで取得し CloudWatchのカスタムメトリクスにすることで様々な監視をAWS上だけでも 実現出来る。 その為、これを利⽤することで⼀定の負荷になったらノードを追加し・・・を ⾃動化する事がインスタンス起動時にCassandraレイヤとして必要な処理を設 定するAuto Scalingと連携することで可能になる。
  46. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Using Multi-Region Clusters 初めに解説したクラスタ構築例は単 ⼀リージョンを想定しているが、こ の項⽬ではマルチリージョンでの構 築について解説している。 主な違いはリージョン間でどのよう な通信をケアしなければいけないの かという点にスコープを当てて解説 をしている。
  47. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Using Multi-Region Clusters また、マルチリージョン構成ではど のようにリクエストが処理されるか についても解説。Consistency Level でLOCALかEACHを使うとどのよう な違いになるか、もしリージョン間 の通信が切れてしまった場合に Cassandraのhinted handoffの仕組 みによるカバーも解説
  48. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Performing Backups Cassandraのバックアップをどのように取得するか • PriamなどのOSSツール • Amazon S3 • EBS Snapshot などの⼿法について。 これはどのインスタンスを利⽤したか、インスタンスストアにsstableなどの データが存在するかにも依存するので、ケース・バイ・ケースで選択を。 フルバックアップなのか、それともノード単位でのスナップショットになるか など。
  49. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Building Custom AMIs この項⽬ではカスタムAMIを作る利 点について解説。 最⼩限構成のOS設定から起動をする とCassandraのインストールから JDKや各種運⽤上必要なツール設定、 agentの設定などの処理が必要となり ⾮常に⼤きな時間が掛かる為、可能 な限りカスタムAMIを作りそれを Golden Imageとして運⽤するのが推 奨。カスタムAMIを作成する⽅法に ついてもWhitePaperがあるので、是 ⾮参考に。
  50. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Migration into AWS オンプレ環境からCassandraクラスタをAWS上にゼロダウンタイムで移⾏す る⼿法について 簡単なステップの解説としては既存クラスタ(DC1)とAWS側クラスタ (DC2)として • AWS上でDC2構築 • DC1とDC2にデータがレプリケーションされるようにkeyspaceを更新 • 全てのデータ同期が完了したらアプリケーションからDC1への接続を⽌め る • 動作が問題無ければDC1をクラスタから外し削除する という流れになる。
  51. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Analytics on Cassandra with Amazon EMR この章ではCassandra内のデータ分析としてApache Sparkを使う場合に Amazon EMRを利⽤する⽅法などを紹介。 構築構築としてAmazon EMRを利⽤することで⾮常に簡単にApache Spark の利⽤をスタートする事が出来る。 またEMRクラスタのノード台数変更なども柔軟に⾏えるため、⼀時的な解析 利⽤などですぐに落としてしまっても構わないパターンや、様々な解析⽤途の ワークロードが⾛るのを⼀つのクラスタで制御するのではなくワークロードに 応じてクラスタを構築する事が容易に可能となる。
  52. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Optimizing Data Transfer Costs Cassandraクラスタを構築した後に発⽣するNWコストをどのように最適化す るか AWSでは条件に応じてNW転送量に課⾦が発⽣するため、例として無駄な public IPベースでの設定を⾏わない、可能な限りデータを持っているノード と通信する事でstorage proxyのレイヤで発⽣する通信を削減する、また Netflixが公開しているAstyanaxを利⽤する事で、更に最短経路をクライアン トが取るようになる⼿法などを紹介。 また、Cassandra側の圧縮機能有効化やread repairの設定なども紹介してい る。これらの⼿法を使う事でコストの最適化と合わせてレイテンシの削減にも 寄与する。
  53. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Benchmarking Cassandra この章では構築したCassandraクラスタへのベンチマークソフトとして • Cassandra-stress • YCSB を紹介。 具体的な使い⽅というよりはAWS環境と⽐較するために各環境でベンチマー クを⾏う場合の注意点を解説している。⾮常に簡単にまとめると同じ条件を可 能な限り再現するべきという内容。設定はもちろんだが、スペック、実⾏場所 などに特に注意を。
  54. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. Using the Cassandra Quick Start Deployment この章ではCassandraをAWS上で構 築する為に、 DSEと CloudFormationによる構築⾃動化を 紹介。 このような解説ドキュメントも⼀緒 に公開されており、⾮常に簡単にス タート出来る。このドキュメントで は実際のオペレーションなども解説 しているため、本Whitepaperと併せ て是⾮⼀読頂きたい。
  55. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 最後に AWS上でCassandra構築するメリッ トとして • セキュリティ • スケーラビリティ • Cassandraを運⽤する上で便利な 各種AWSサービス があります。White Paperと本セッ ションがこれから構築を考えている ⽅に少しでも⽀援出来れば幸いです。 多くのお客様の実績も既にあります のでお気軽に相談下さい。
  56. © 2017, Amazon Web Services, Inc. or its Affiliates. All

    rights reserved. 最後に 詳細を紹介しきれていない各種AWS サービスの機能については AWS Black Belt Online Seminarと いうオンラインセミナーの資料を公 開しています。是⾮こちらを⾒て頂 ければ助かります! 「AWS Black Belt VPC」というよう に検索して頂けばslideshareのプレ ゼン資料にすぐアクセス可能です。