「AWSにおけるCassandraクラスタの設定と運用」を聞いてきた（ただホワイトペーパーある）

Cassandra Sammit Tokyo2017のメモ続き
午後のセッション

表題の件は、後半
「AWSにおけるCassandraクラスタの設定と運用」

ホワイトペーパーは
https://d0.awsstatic.com/whitepapers/Cassandra_on_AWS.pdf

---

■KafkaとCassandra(DSE)とSQLiteで毎時２７００万レコードをR/Wするには？

・Kafka：コミットログ
・DataStaxEnterprise：永続化
・SQLite：検索
・ＣＳＶの読み込み、書き込み
システム構成

ＣＳＶ→プロデューサー→ブローカー→コンシューマー→ＤＳＥ
　　　　　　　　：　　　　　　　　　　　↓
　　　　　　これ１２００個　　　　　SQLite

・問題発生
・Kafka停止：５分くらい
　Kafkaはトピックとパーティションが増えるだけ、メモリが必要
　　→ヒープがいっぱいに:ヒープ設定しましょう
　　　（最初は出なかった）
　※公式にはあまり書かれていない。べストオブプラクティスに

・ＤＳＥ停止
　書く容量がなくなった（正常に止まった→正しい動作）
　→２ノードに集中していた：ＫａｆＫａのノード分布が極端に偏った
　　　→ＺｏｏＫｅｅｐｅｒの安定稼働が必要
　　リーダーノードの分布：ころころ変わる

・ファイルディスクリプタ不足
　nofile設定(TIME_WAITのソケット回収 tcp_tw_reuse
　　→recycleは使わない）

・ＣＳＶパースが重い
　投入データに応じてパーティションに振り分ける場合、データの偏りがないようにする

・MSGPack重い（not 遅い）
　構造化されたデータだと重い
　割り振りのＣＰＵ
　CPickleにすると早くなる

・スケールアウト型の良い点・悪い点
　環境設定の自動化：Ansible
　大量のデータが流れる→データのエラー
　ＲＤＢだったら？　できるはずない。

・補足：トランザクションミドルウェア

・事例紹介
　テレマティックス
　治験アプリ

■Best Better practice of Cassandra
　Cassandraに不向きなCassandraデータモデリング基礎

・自己紹介
・ターゲット
・ベタープラクティス
　ベスト：適材適所というけど
　ベストじゃない部分：ＲＤＢ？→それやるくらいならＲＤＢに入れる

・ベストではないけど、Cassandraに入れれるよ
　　→ＲＤＢにいれなくて、Cassandraで行うために
　・ヒストリカルデータ
　・ツリー構造
　・計上データ

・前提条件
　Cassandraはどうやってデータを読むか
　　パーティションキー、クラスタリングキーの２つのキー
　パーティションキーのハッシュ
　カラム名がクラスタリングキー、
　それ以外が値

　パーティションキーは＝かける。必須
　クラスタリングキーは前のところから指定
　最後は＞　＜　が書ける

・履歴管理：社員の異動情報　３月２５日の時点
　ＳＱＬなら　開始日付と終了日付ではさむ
　→カスタムインデックスを作る

・ツリー構造
　組織構造
　方法
　　連結リスト
　　ねすてっとテーブル
　　経路列挙
　　クロージャーテーブル
　判断のポイント：
　　ＪＯＩＮ，再帰不可、
　　整合性は考えないとする
　　ジェイウォーク：１つのカラムに複数の値を入れる、非正規もＯＫとする

　経路列挙とクロージャーテーブル
　　経路列挙：コロン区切りでつなげる
　　　→前方一致
　　　；でsplitする
　　　U+003A以上 U+003B未満でコロンを指定できる

　　閉包テーブル
　　　距離を書く
　　　レコード数は増える

・計上データ
　　伝票集計データ
　　　誤計算は死
　　　並列・ストリーミング
　　　高速処理

　　カウンターは、特定状況で２回カウントされるのでＸ
　　update with ＬＷＴ（100だったら101にする）

■（英語のタイトルで、全部英語：通訳なしで、タイトルメモれなかった）
・リアルタイム分析でCassandraとSpark
・自己紹介
・リアルタイムの意味
　たいせつなところ
　ユースケース
・Cassandra
　ＮｏＳＱＬ
　Ｎｏ　ＳＰＯＦ
　なぜ、Cassandra
　　　ＳＰＯＦがない、信頼性など
　ユースケース
　　　ＩｏＴなどいろいろ

　ＣＡＰ定理
　　Cassandraは　ＡＰ
　　コンシステンシーとスピード、ボリューム

・ＳＰＡＲＫ
　エコシステム：機械学習など
　　Ｓｐａｒｋ　Streaming→MLlib,SQL

・Ｓｐａｒｋ＋Ｃａｓｓａｎｄｒａ

・Ｓｐａｒｋ　ＡＮＤ　Ｃａｓｓａｎｄｒａ　アーキテクチャ

（早く終わった）

■運用中システムにおける６億レコードのデータ移行に関する課題と解決
・自己紹介
・ログデータ蓄積・解析システムの概要
　　IoTサービスのログデータ解析
　　ＩｏＴデバイス
　　　ログデータ→Ｃａｓｓａｎｄｒａ
　　　データ　Ｈａｄｏｏｐで解析
　　　　　　　ＲＤＢに保存

　集計項目　２０項目（蓄積用とは別）

・データ移行が必要になったわけ
　ユーザー固有の情報を取り扱う
　　→蓄積用カラムファミリに主キーの追加が必要となった
　　→後から変えられない

・移行要件
　サービスに影響を及ぼさない
　新規カラムには、１レコードずつ適切な値を入力

・設計指針
　低負荷：全件SELECTとかしない
　高速：早く移行を終わらせる
　リトライ可能：同じデータを２度処理しない

・方法案
　Hadoop Map Reduceの利用→MapperのTimeoutで失敗する
　マルチスレッドで行う→いったん採用
　　１時間分などもできる
　　確認：ＲｏＷ　Ｋｅｙでカウント

■AWSにおけるCassandraクラスタの設定と運用
・ホワイトペーパーがあり、それの解説となる
http://bit.ly/2wwdWa7
・自己紹介
　100 node cluster admin oparator
・本セッション
　ホワイトペーパーベース、各章・項目の紹介・解説
・「Ａｐａｃｈｅ　Ｃａｓｓａｎｄｒａ　ｏｎ　ＡＷＳ」について
　ＯＳＳプロダクト運用に役立つドキュメントを出している
　Ｃａｓｓａｎｄｒａ　２．１ベース

・主要なＮｏＳＱＬデータストア
　Ｃａｓｓａｎｄｒａはキーバリュー

・ＮｏＳＱＬ　Ｏｎ　ＡＷＳ
　ＮｏＳＱＬ：ＤｙｎａｍｏＤＢ

・Cassandra: A Breif Introduction
　Cassandraの基礎的な知識について
　重要となる要素
　　クラスタ
　　分散の考え
　　ノード
　　コミットログ
　　memtable
　　　：

　ＡＺと合わせて考える

・ライト・リクエスト・フロー
　　書き込み処理の流れについて
　　文があっている・図は間違ってる

・コンパクションについて
　理解してなかったら読んでね

・リードリクエストフロー
　　読み込み処理の流れについて

・リソース要求
　　ストレージ
　　ネットワーク
　　メモリー
　　ＣＰＵ

　ストレージ
　　Ｄｉｓｋ　ＩＯ大事　シーケンシャル＋ランダム→ＳＳＤ
　　etx4,etx3

　ネットワーク
　　リクエスト処理、Ｇｏｓｓｉｐ
　　１Ｇｂｐｓが利用できるインスタンス
　　ＮＷ最適化オプション

　メモリ
　　　重要な設定
　　　　MAX_HEAP_SIZE
　　　　HEAP_NEW_SIZE
　　３２Ｇ以上：ただし２．Ｘ
　　３．０はＧ１ＧＣで変わってるかも

　ＣＰＵ
　　Ｒｅｄｉｓだと、コアをみてくれないので１コアでインスタンス増やす
　　ＣａｓｓａｎｄｒａはＣＰＵが４個以上あるインスタンス

　ある程度のスペックを持ったインスタンスでクラスタのノード数を抑えることが
　管理コストの観点からよい

・ＡＷＳでクラスタ設計する
　ＡＺ
　ＶＰＣ
　ネットワーク
　ストレージ
　インスタンス

・そもそも、ＡＺ，リージョンとは
　リージョン：物理的場所
　ＡＺ：１つ以上のデータセンター
　→マルチリージョン構成

・すにっち
　　自動的にセットしてくれる
　　単一リージョン
　　マルチリージョン：いくつのレプリカ持つか

・ＶＰＣの設計
　ＶＰＣ：サブネット
　ＶＰＣ：仮想プライベートクラウドサービス

・ＥＮＩ（えらすてぃっく　ねっとわーく　いんたーふぇーす）の設計
　Ｅｔｈ１，Ｅｔｈ２が簡単に作れる
　ＩＰを引き継いだノードが作れる

・ストレージ性能の設計
　　ＥＢＳ　→永続的
　　ＥＣ２　インスタンスストレージ
　　　　　　→ＶＭが起動するところについている一時的ストレージ
　　　　　　　ＮＶＭえＳＳＤなど利用できる
　→パターンを説明
　　要件に合致しているか

・インスタンスタイプ
　どういうシナリオで、どういうサイジング
　ノードの追加でスケーリング

・カサンドラをＡＷＳにデプロイ
　クラスタでどこまで高可用性を追求するか？
　Ｗｒｉｔｅを安全に失敗させるとか
　オートスケーリングとＮＡＴ　Ｇａｔｅｗａｙ
　　→シードと、ノーシードで
　セキュアなＣａｓｓａｎｄｒａ
　　→ＫＭＳ

・Ａｍａｚｏｎ　ＣｌｏｕｄＷａｔｃｈの利用
　　→監視　一定の負荷になったら、Ｃａｓｓａｎｄｒａを追加

・マルチリージョン構成
　　通信
　　リクエスト処理 hinted handoff

・バックアップ

・カスタムＡＭＩを作るメリット

・オンプレ環境から、ＣａｓｓａｎｄｒａクラスタをＡＷＳ上にゼロダウンタイムで移行

・ＡｍａｚｏｎＥＭＲを利用したＣａｓｓａｎｄｒａ上の分析

・ネットワークコストの最適化
　　→ＮＷ転送量に課金

・カサンドラのベンチマーク
　ＹＣＳＢ：注意点

・クイックスタート
　DSEと、CloudFormationを使う

・ＡＷＳで作るメリット
　　セキュリティ
　　スケーラビリティ
　　各種サービス

・ＡＷＳ　Black Belt Online セミナー
　　ＡＷＳ　Black Belt VPC等で検索するとプレゼンへ

---

午前と午後の間にランチセッションがあったけど、
それについては、別エントリで

Cassandra Summit Tokyo 2017の途中経過

Cassandra Summit Tokyo 2017の午前中メモメモ

---

■司会
・第５回になります

■Key Note(英語、通訳なし）
・自己紹介
・日本に初めて来たとき
　　渋谷　３年前　話にきた→日本のコミュニティと話した
・コミュニティについて
　ディストリビューションいっぱい
　コミュニティサポートがないのは、旅で一人で道をあるくこと
　　→コミュニティの意義
・コミュニティによる強化

・かサンドラ動かすのにベンダーのである必要はない

カサンドラプロジェクトの状態
・ＴＩＣＫ　ＴＯＣ　ＬＥＧＡＣＹ
　ＧＯＯＤ：２．２
　ＢＡＤ：３．０，３．１１、とらんく
→どのバージョン使えばよい
　２．２　ローリスク
　３．０　ステーブル　tic/toc
　３．１１　新しくステーブル

・マテリアライズド：ビュー
　　Just fix 11500
　ハッピーパスは、ナロー

・４．０
　　No More THRIFT :(

・バグ修正と改良
　２０以上のバグフィックス
　PULL　REPAIRもある

・新しい機能
　タイムスタンプ機能 SELECTで
　算術演算子　％も
　内部ノードのメッセージングでの書き換え（リライト）

・実装しやすくなった
　　１メッセージで挿入、とらんけーと
　　Dcassandra.write?survey=true
　　トラフィックにＳＳＬクライアント証明 10404

・次は？
　仮想テーブル
　プラガブル　ストレージ　エンジン（新しくないけど）
　　　Dynamo+MySQL etc
　　　Mycassandra
　　　2995
　ROCKS DBのインテグレーション

・ＪａｖａのＧＣ
　→レイテンシ―
　
・プラガブル　ストレージ

・ＦＩＸしたバグ：リアルワークロードからのディスカバリー

Ｔａｎｋｓ！

■日本Cassandraコミュニティの話
・(そのまえに今日の）ランチセッション、懇親会の話
・日本Cassandraコミュニティ
　　情報共有
　　http://cassandra-jp.com
　　メーリングリストcassandra-jpでGoogle Groups
　　Cassandra勉強会　３８回　最近は１５名から２０名くらい
　　Cassandraカンファレンス
　　Cassandra飲み会　不定期
　→アメリカだと７位だけど、日本だと難しいのかなあ～

■DataSTAX　きもとさん
・ことしの７月日本法人
・クラウドアプリケーションがビジネスを変える
　急速に進化する世界
　革新がおこるたびに期待が加速

・クラウドアプリケーションは期待に応えることを求められる
　　エクステンチュアル
　　常時オン
　　リアルタイム
　　分散型
　　スケーラブル

・データプラットフォームの要件
　　常時オン
　　無理なくスケール
　　今を知る

・今を知る
　　サーチ：全文検索（そーら）
　　アナリティクス（Ｓｐａｒｋ）
　　グラフ
　→オールインワン：DATASTAX ENTERPRISE

・ＤａｔａＳｔａｘはクラウドアプリケーション向けの

・Cassandraアプリケーションの作り方　Ｅ：１５：４５～

■YAHOO
・講演案内
・講演以外のとりくみ
　　Openstack
　　高集積サーバー
　　Kukai（くうかい）：スパコン　Green500で世界第二位でCassandra？
・Cassandra Summit NGCC
　　NGCC:DSXのこみったーあまりいなく、apple、インスタから
　　　→DSXのコミット数も減っている
・ブース

■INSTACLUSTR
・オープンソースで高信頼性とスケールする
　→Casaandra,Syclla,Sparkとか使ってる
　→モニタリング、修復、バックアップ
　→２４時間３６５日のサポート

■マイクロソフト
・Cassandera＋Azure
　Windows Azure→３年前からLinuxもしたけど、
　Azureのアイコンを変えた Azure Open Source
　
・IN THE FORESTで

・Azure：プラットフォームとして使ってほしい
　海外：フォーチュン５００　の９０％
　　　　Ubarの顔認証：動画でコグニティブサービス

・トラスティッククラウド

・第一生命の事例：データセンターの監査対象
　リージョン：世界最大　南アフリカにも
　ネットワーク：軍についで高速

・自社内でＣａｓｓａｎｄｒａ
　MyAnalytics：ログを採ってアドバイス

・Azureオープンソースデータプラットフォーム
　　ＤＢたくさん選べる
　　Kafka→Cassandra→Ｓｐａｒｋ，ＡＩ→活用

・２つのリージョンを使って
　コンテナイメージをＰａａＳで

・信頼できるクラウド

■楽天
・会社紹介
　２０１０年ころ　外国籍の人
　今　外国籍の人ばっかり
・Ｃａｓｓａｎｄｒａ
　２年前にえらんだ
・Rakten tech カンファレンス