diaryこの広告は、90日以上更新していないブログに表示しています。2019-09-09ISUCON9への出場と敗北ISUCON9に出場してきた。自分という大人気ない面子で出場して負けてしまったので、非常に悔しい。大した活躍が出来なくて申し訳なさで一杯である。最終スコアは5000ちょいぐらいでしたが、3台分のリソースを全然回せなかったので、アプリサーバのCPUまでネックを移せれば予選突破レベルだったかなあ......。N+1解消手法の選択ミスN+1を解消するのにJOINを使ってしまったことが一番問題だった。byの範囲を絞らないと何をやってもDBネックが消えなかった。BY狙いのindexが全然効かせられなくて、時間使い切ってしまった。早めに方針転換してクエリをバラす方向に触れれば良かったかもしれない。BYが効く様にした上で、IN句を使って他のエンティティを取得しアプリ側で結合するのが妥当だったと今なら思う。Cloudのインスタンス起動に失敗し起動がロックされてしまった。結果、インスタンスを起動してソースコードを得るまでに1時間ぐらい時間がかかってしまった。ソースコードの分量が多くて読んで状況を把握し、実際に作業に入った時点で昼前ぐらいだったと思う。完全な負け惜しみだが、そこで無駄にした時間が無ければもう1手打てたかもしれない......。エラーハンドリングの適正化エラーハンドリングがかなり厳しいコードで、地道にコード直してAPI呼び出しやスタックトレースがまともにロギング出来る様に最初に改修しておくべきだった。エラー発生時の情報取得が上手くできてなくて、かなりの時間を無駄にした。結果、出来ることがかなり減ってしまった。上手くいったことモリスさんがマルチスレッド化をサクっと実装してくれたため、そこで最低限のスコア上昇は得られた。そこはやれば上がるのは分かり易かったし、我々はこういうコードを書くのは最近得意であるwというわけで、ここは数少ない上手くいった箇所だったと思う。反省と負け推しみある程度やる事自体は見えていたのだが、完全に手数が足りなかったり、DBネックを潰し切れなかったのが致命傷になってしまった。bcryptを別アルゴリズムにしていいというのは完全に思い付いていなかった。そこに負荷がかかっているのは分かっていたが、ルールに対する思考の柔軟性が無かった。総合的に柔軟性を失っているなあということを感じた。後、面倒臭いことに我武者羅に突っ込むのを躊躇してしまったかもしれない......。おっさんになるとはこういうことなのかと思った次第である。言い訳と負け惜しみを書いておくと、私自身クライアントから直接アクセスが来る様なWebアプリケーションを最近全く書いてないので、完全に勘とか手の早さを失っていると思った。インデックスという概念が無い全スキャン前提のDWHとかパーティションキーでデータを取得するCassandraとかに対して1000万件オーダーでデータを取得する様なクエリばっかり書いてるし、データパイプラインのスケーラビリティとかストリーム処理に関するコードばかり考えていて、Webのページネーションとかをちゃんと実装する、みたいなことから遠ざかって久しい。昔取った杵柄みたいなものでいつまでも戦える程簡単なものではない様だ。これはISUCONという大会が良く出来ているという話でもあるので、悪いことではないだろう。チームメンバーが強力だっただけに辛さが3倍である。次回はどうだろうなあ。Streamsを使うことにしたので、動作概要とストリーム処理のイメージについてまとめておく。kafkaそのものについては今更説明の必要は無いだろうと思う。Streamsはkafkaを基盤にして分散ストリーム処理を簡単に書くためのDSLライブラリ。https://kafka.apache.org/documentation/streams/延々流れてくるデータを変換して別のtopicに流したり、時間のウインドウを区切ってカウントした結果を流したり、みたいなのがサクっと書ける。Flinkなんかと似た様なことができる。Streamsが良いのは以下の点。groupとtopicの仕組みに載せているので別途ミドルウェアを必要としないなので、kafkaが動作している環境ならJavaのCLIツールを書く様な感じで分散ストリーム処理が実装できる。簡単な例だとこんな感じになる。Streamsの動作について解説する。大まかな概念としては、https://kafka.apache.org/23/documentation/streams/core-conceptsに書かれているが、StreamBuilderクラスに生えているDSLメソッドを使ってノードを作成し、それをグラフ上に繋げていくことでストリーム処理のパイプラインを構築することになる。あるトピックからデータを取得するSourceノード、値を変換するProcessorノード、グルーピングするProcessorノード、aggregationを行うProcessorノード、別のトピックに書き出すSinkノード等を繋げて処理を構築することになる。実際の実行モデルについてはhttps://kafka.apache.org/23/documentation/streams/architectureに記述がある。slideshareで見つけた資料から引用させてもらうとこんな感じ。Groupの各パーティション割り当て毎にタスクという実行単位が作られる。タスクは一連のストリーム処理を実行する。Threadの中で起動し、一つのスレッドの中に複数のタスクを持つことができる。スレッド数に分散して割り当てられる。Groupを使って管理している。注意点として、一つのストリームスレッドで複数のタスク(つまり複数のパーティション)を処理できるが、スレッドが共有だと一つのパーティションのデータを処理している間は他のパーティションのデータ処理は待たされることになる。Streamsはラムダで一連の処理が繋がっているかの様にコードを書くことができるが、実際に一つ一つのラムダ式として記述された内容は常に同一のスレッドや同一のノードで実行される訳ではない。レコードのキーを変更する操作を行うとrepartitionが発生し、一旦kafkaの中間トピックを介して別タスクに処理が移ってから続きの処理が実行されることになる。その別タスクは完全に別ノードで実行されるかもしれないし、別のスレッドで実行されるかもしれない。各ラムダに書いたものは完全に独立した処理としてコードを書かなければならない。スコープ外から持ち込めるのはstaticで各ノードで共通であることが分かっているものぐらいしか使ってはいけない。ストリーム処理を実装する上では、あるパーティションのロカリティを考慮した実装することが重要になる。同一のパーティション数であれば同じパーティション番号にデータが配置される。Threadに処理が割り当てられる。Threadで処理されることが分かるので、集計処理を行うことが可能になっている。Store)を持っているかを考えながら実装する必要がある。DSLで構築したパイプラインは大きく分けてKStreamとKTableという二種類のモデルで表現される。公式リファレンスによると、KStreamはレコードストリームの抽象、KTableは変更ログストリームの抽象と説明されている。詳しく説明するとそれぞれ以下の様な感じで動く。KStreamは一つ一つのレコードがデータとして完結しており、全てのレコード一つ一つをそのままストリームデータとして扱う。KTableは一つのレコードは変更履歴情報であり、ストリーム処理で流れるデータは変更履歴を集約した最新の状態を表すレコードになる。テーブル上に存在する更新可能なレコードの様に扱うことができるのでKTableというのだと思う。Kafkaはストリームバッファなので、KTableの様なデータを扱うためにはストリームの開始時点から現在までのデータを全て読み出して再生しないと最新の状態を復元できない。Storeという領域に最新の情報を保存する形になっている。Storeが存在する。StoreはRocksDBという埋め込み型のデータベースをKVSとして利用してデータを保存している。Streamsではグルーピングして集計するという様な状態を保持したストリーム処理はKTableとして表現される。Storeが必要になる。両方ともストレージを消費するので、KTableとして扱うデータが多ければ多い程各ワーカーのローカルストレージ領域が必要になる。KTableデータの保持期間ストリーム処理でデータを集計する際には、タイムウインドウを区切って集計するのが一般的。タイムウインドウを1時間で集計しているとして、そんなデータを何週間も保持しなくて良いことの方が多いだろう。いう処理で無駄なデータを保持し続けない様にするために、集計処理毎にデータ保持期間を設定できる様になっている。Streamsは状態を保持する必要がある機能はKafka本体にデータを保持する仕組みになっているので、基本的にワーカーを増やすだけで処理をスケールアウトさせることができる。Groupへの参加申請に伴うrebalance処理にそれなりに時間を要する。そのため、頻繁にワーカーが出入りする様なオートスケールを使ったコスト節約方法とはかなり相性が悪い。ちなみにrebalanceにかかる時間に対する改善策は開発コミュニティでも議論されていて、今後は高速化されるかもしれない。Foundationそういう訳なので、レストアスループットを向上させるためのチューニングや頻繁にノード数を増減させなくていい様なスケーリングが必要になる。Groupから離脱してしまうため、いくつか安定稼動のために重要なconfigがあったりする。Groupから離脱する。通信状況や負荷などによって処理が詰まった場合、復活したり離脱したりを繰り返して延々処理が進まなくなる可能性があるので、ある程度余裕を持った値に設定しておいた方が良さそう。Groupから離脱する。これも上記と同様の理由である程度余裕を持たせた方が良いだろう。一回のpollingで取得するレコード数。Groupから変に離脱してしまう可能性がある。あるパーティションから一度に取得できるデータ量。レストア処理のスループットに影響する。TCPのRCVBUFの値を設定する。デフォルトが65535と現在のネットワーク構成からすると少ない値になっているので、設定しなおした方が良い。当たり前の話だが、そもそもデータ量を減らすのは大事なので、バイナリシリアライズフォーマットを採用したりしてトラフィックを削減するのも重要になる。終わりにまだ本格的に運用しているという段階ではないので、他にも考慮点やチューニングポイントが出てくるだろうと思う。Groupのrebalanceとレストア処理のリードタイムについては多少不安が残っている。言っても、必要な機能は十分に揃っている印象で、追加のミドルウェア無しで実用的な分散ストリーム処理が書けるのは非常にありがたい。調査と実験を続行して本格運用に乗せていく予定。2019に参加し登壇してきました。Ruby」というタイトルです。speakerdeck.com実装はこちらです。READMEの整備が全然出来てないのと、APIがまだ変わる可能性があるので、gemとして正式リリースするのはまだやってないのですが、近々ちゃんとリリースします。github.comRuby黒魔術師として、自分が良いなと思っているデザインパターンであるモナドを、Rubyの世界で理想的に表現するならどうなるかということを考えて発表テーマとしました。今回、ASTがRubyレベルから簡単に触れる様になったので、それを活用してみたかったというのもあります。内容としてはAST変換を駆使して、あるパターンの変数代入構文を乗っ取り、flat_mapのネストに置き換えた状態でProcとして再評価することで、モナド記法を実現しました。厳密にモナド則を守る機構は用意してないですが、Scalaでも確かflatMapがあればfor式は使えたはずなので、その辺りは割り切りかなと思っています。大体、Scalaの発想をパクった感じですね。したいことを色々詰め込み過ぎた感じがあり、実装の紹介が中途半端になってしまったなと自分では思っています。アフターパーティで松田さんと話をしましたが、RubyKaigiの登壇者は前提知識のレベルとかある程度すっ飛ばして、もう話しをしたいコアの所ばかり喋っているから面白いという話が出ました。私もその通りだなと思いますし、予習資料だけ提供して色々振り切ってしまった方が盛り上がる発表になったかもなあと反省しました。去年はコンビ発表で、ソロでRubyKaigiに出るのは初登壇だったので、ちょっと気負い過ぎたのかもしれない。来年は今年みたいに4パラトラックにするのは、どうやっても無理だという話も耳にしたので、CFPの競争率は更に上がることが予想されます。そんな中で来年も上手く刺さりそうなproposalが出せるかは全く分かりませんが、今回の反省を活かせる様に何とか頑張っていきたいと思います。体調不良について今回、開催日前日に急に38度を越える発熱があり、関係者や友人各位に多大な心配をかけてしまい、申し訳ありませんでした。前日まで全く異常が無く前触れも何も無かったので、正直大分焦りました。結果的にこじらせることはなく、何とか初日の登壇もこなせましたし、2日目には平熱まで熱が下がり無事RubyKaigiを楽しむことができて、本当に良かったなと思っています。インフルじゃなくて本当に良かった......。(前日に美味しいものを食べたり、ESMスポンサードのクルーズに行く予定があったのに、全てキャンセルすることになったのは、めちゃめちゃ辛かったですが......)今回得た教訓は、やはりロキソニンとユンケルは効くということです。後、無理のし過ぎは良くない。俺の肉体に何があったんだろうか......。ストレスとか緊張とかかなあ......。リアルなWebアプリケーションを高速化しようとしたら、非同期I/Oは重要になるしマイクロサービス化してくると影響も大きくなる。現実的な高速化施策として、納得感が強かった。マジで待望の機能です。文法はまだexperimentalですが、既にtrunkで使えるってことなので、早速試して手触りを確かめているところです。挙動をアドホックに切り替えたい時はRefinementsがちゃんと使えるということなので、これでRefinementsのユースケースも増えるし最高では!という気持ちです。今回、LTのスピーカー勢が非常にエクストリームな人ばかりで、大体趣味の話がおかしくて面白かった。「○○したくなると思うんですけどー」みたいな語りで言ってる内容が大体ブッ飛んでる。(他人のこと言えないだろ、というツッコミもあるかもしれませんが......)後、内容に割と関連性のあるトークが多くて、ストーリー性が垣間見えて良かった。Differential繋がりだったり、TracePoint繋がりだったり。今回、私の所属企業であるReproでRubyKaraokeスポンサーをやらせてもらいました。ランク的にはプラチナスポンサー相当になります。RubyKaraokeは非常に楽しいし、カラオケは自分の大事な趣味の一つなので、スポンサードできて非常に光栄です。100を越える参加者が来てくれて、そして概ね楽しんでいただけた様だし、スタッフとして手伝ってくれた弊社メンバーも楽しめた様なので、良いパーティに出来たかなと思っています。実は私はRubyKaigiのスポンサー企業の一員としてRubyKaigiに参加するのはこれが初めてだったりします。それがRubyKaraokeスポンサーだったのは運命みたいなもんですねwしかし、RubyKaraokeは例年非常に深夜まで続くので、3日目の午前のセッションに間に合わないことが多いんで、それが良し悪しだなあと......。(いや自分の理性の問題もあるんですが、今回ばっかりは自分ではどうにもできない......。体調の問題もあり、食事方面では不完全燃焼感が強い。写真も余りストックが無いので割愛。ホテルの近くにあった、長浜ナンバーワンが割と美味しい長浜ラーメンで良かったなという感じです。魚はとても美味しくて、やっぱ海側ってのは強いなと実感できる美味さでした。ベストシーズンでは無かったみたいですが、ゴマ鯖は美味しかった。活イカが食えなかったのが、本当に残念でならない。まとめ今年のRubyKaigiも最高に楽しかった。それしか言うことは無いですね。今年も開催してくれてありがとうございました!スタッフの皆様、スピーカー、スポンサーブースの皆様お疲れ様でした。2018のRubyKaigi関連トラックに採択されたので、登壇するためにロサンゼルスまで行ってきました。RubyKaigiトラックということで、内容はRubyKaigiの再演でした。学生の時にめっちゃ貧乏だったのもあって、今迄海外に行く機会が全く無かったので、実はこれが初の海外旅行であり、当然ながら英語で発表するのも初めてだったので大分緊張しましたが、本番ではそれなりにウケたという手応えがあったので、今迄の登壇経験が上手いこと活きたんだろうと思っています。(後で松田さんとそらはーさんに、めっちゃ発音突っ込まれたけど......)共同登壇者であるtagomorisさんには、トーク以外でも色々と滞在中にお世話になったので改めて感謝を!ありがとうございます!録画はあるらしいので、もうちょっとしたらyoutubeとかに上がるだろうと思います。発表の仕方については、流石に普段英語全然喋ってないので、テンパって飛ぶとヤバイだろうと事前に原稿をある程度書いて発表者ノートにまとめておくというスタイルでやりました。プレゼンの原稿ちゃんと書いたのは、これが初めて。一応、そのまんま読むのは止めようと、イメトレして何パターンか作っておいたので、読みながら適宜合わせるぐらいの事は一応できたと思う。Job"って言われて嬉しかったという、テンパらずに済む形になって助かりました。Workとか、Amazingとか言われたので、通じなかったってことは無さそうで安心しました。(というか日本がキッチリし過ぎというか)トイレで流すボタンが反応しなかったり、シャワーの出し方が分からなかったり、水量と水温を一つのレバーで操作しようとする謎UIだったり、自販機で売ってるものの値段が全く分からなくて1ドル札しか使えなかったり売り切れ状態が分からなかったりする。一方で、フリーWiFiが本当にあちこちにある。後、Uber/Lyftが真の力を発揮できて、どこに行くにもサクっとタクシーに乗れて決済も簡単に済むというのはめっちゃ便利だった。人もでかいし、歩道も通りもでかい。交差点間の距離がめっちゃ長い上に単位がフィートなんで全然感覚分からなくて、コンビニが2ブロック向こうかーと思って歩いたら15分ぐらいかかったりする。日本じゃ長くて3分だぞ......。肉とビールに関しては最高だった。ロサンゼルスはローカルブルワリーが一杯あるみたいで、ビール好きにとっては最高の街だと思います。後、海産物系は全体的に選択に失敗した感じで、大体駄目でした。CounterのBTOバーガー。実際めっちゃ美味かった。フィッシュマーケットみたいな所でシュリンプカクテル頼んだけど、クソ辛かった......。StraussはAsakusa.rbのLA支部と言って差し支えないレベルだと思う。本当に最高だったのでLAに行く機会がある人は、是非行くべきだと思う。観光カンファレンス後に1日空けておいたので、その日にロングビーチまで観光に行きました。目的は、アイオワ級戦艦のネームシップであるアイオワを観に行くことです。中がミュージアムになっていて色々見て回れる様になっている。映画「バトルシップ」に出てきた戦艦はアイオワ級のミズーリで兄弟艦にあたるはずですが、実際見るとまんま映画で見た奴だ!ってなりました。後は、役目を終えてホテルになってる豪華客船クイーンメリー号と近くにある潜水艦スコーピオンを見に行きました。なんというか、アイオワもそうだったがでか過ぎる!後はこいつに乗りました!電動で動くキックボードみたいなやつ。実際乗ってみたら、めっちゃ楽しかったけど、思いの外加速が凄くてアクセス全開にしたら30km/hぐらい出るし、車輪がすげー小さいので段差とかあるとめっちゃ危ない。こんなもん国土がクソ広くて道が無駄に広い国じゃないと危なくて乗れたもんじゃないし、絶対日本の公道で乗るのは無理だと思う。いうかアメリカでも十分に危険だと思うので、その内規制されるんじゃなかろうか......。今の内に乗れて良かったと思う。まとめというわけで、RubyConfで登壇しにロサンゼルスまで行き、ついでに観光してきた訳ですが、全体としてはとても良い経験になりました。アメリカを一部でも経験できたし、美味いビールと美味い肉は食えたし、英語で登壇するという経験ができたので、RubyKaigiでも英語で話せるかもなあという自信が付きました。(やるかは分からんけど......。リスニングは結構苦労するというか、周りがごちゃごちゃしてると全然分からんし、早口で喋られると何言ってるか分からなくなる。コミュニケーションは取れなくもないという感じでしたね。慣らさんとなあ......。ありましたが、今回こういう機会を得ることができたのも、トークに採択してくれた松田さんとRubyConfのおかげです。2018に登壇するためにL.Aまで行ってきたTweet広告を非表示にする2018-06-29本番環境でcassandraの運用を開始してみた職場でcassandraの運用を開始したので、選定理由とか運用してみて得た知見や所感等を書いてみようと思う。(まだ十分に知見を得たとは良い難いので、間違った印象を得ていたり、より良いオペレーションに気付いていない可能性があります。)cassandraの採用理由そもそもの目的はホットデータの書き込み先としての利用です。要件としては以下の様なものがあります。(最悪connectorは書いてもいいが、できれば避けたい)一度に数百万件ぐらいまで読み込む可能性があるので、それなりに読み込みもスケールして欲しいし、レンジスキャンにもある程度効率が求められる。データ加工で潰しが効く様にkafkaの利用も検討してたんですが、データが頻繁に更新される可能性があるので一意のキーでデータが特定できてupsertが可能であり、書き込みレイテンシを小さく保つことができそうということでcassandraに倒しました。Kuduとかも調査はしましたが、ちょっと新し過ぎるのとprestoとの接続性に不安があったので、見送りました。cassandraの構築方法と現在のクラスタ規模ディスクとネットワークにかなりのI/Oがかかるので、コンテナは使わずにpackerでAMIを生成し、EC2で普通に立ててます。cassandraにはseedという概念があり、クラスタの情報を提供するための初期ノードが必要になります。seedは固定でローカルIPを降って3台立ててあり、他のノードはAutoscalingで起動できる様にしてあります。クラスタ全体では10台で運用しています。テーブルは現時点で3種類あり、一番大きいテーブルで50GB程のデータが入ってます。今後利用範囲を広げていく予定です。現時点での利用スタイル利用開始当初は、アプリケーション本体のコードを弄らずに実験するために、fluentdを経由してデータを投入していました。fluentdにデータを流していたので、copyして軽く加工するだけで出力先をコントロールできる様になっています。データを投入するためにfluentdのプラグインを書きました。github.comcassandraは挿入は一件単位で行うことになるので、fluentdの様にbufferチャンクを溜めて処理するのは余り相性が良くないとは思いますが。いうのもfluentdはバッファチャンク単位でリトライすることになるので、チャンクの中の一行がエラーになった場合にどうリトライするかを考えるのが面倒くさい。無視するか全体リトライするかの二択を選べる様にはしましたが......。現在は利用スタイルが固まったので、rubyのcassandra-driverを使ってアプリケーションから直接データ投入する様に変更中です。会社ではdatadogを利用しており、datadogにcassandraのインテグレーションがあるのでそれを利用しています。実態はdatatdog-agentがJMXを介してmbeanから値を取得する形になります。以下の値を収集してます。gc等)加えて、プロセス監視もdatadogでやってます。cassandraの特性についての理解アーキテクチャの細かい解説は、datastaxのドキュメントを読むのが分かり易いと思いますが、cassandraは大まかには以下の様に動きます。cacheを使ってsstableの読み出し先を特定するそれでも見つからない場合は、sstableに含まれるパーティションインデックスからデータの場所を特定し読み込む整合性レベルに応じた結果が集まったら、レスポンスを返す書き込みは基本的にメモリに書かれるし追記しか起きないのでスケールさせやすい。現在のうちの利用規模だと一件辺りの書き込みレイテンシは100μsぐらいで完了してます。(ネットワークレイテンシは別)しかし、読み込みの時はパーティションを特定してクエリするのが必須になるため、クエリのワークロードに合わせてパーティションキーを設計する必要がある。実際、パーティションキーを指定しない形でクエリすることは基本できない様になっている。この点で、読み込みに関してはデータ構造がリッチなKVSに近い。オリジナルのデータが同じでも参照方法に合わせて、テーブルを作る方が良いとされている様です。その分書き込みの数が増えるが、書き込みはスケールさせやすいので読み込み形式に合わせた構造を優先した方が良いということだと思います。prestoからの読み込みパーティションキーを指定しない場合は全パーティションからデータを読むことになる。パーティションキーを指定すれば必要なデータだけ取ってくれる。うまくパーティションが分散できれば、大量に読み込んでもそれなりのスピードがでる。クエリパターンに合わせたテーブル設計が大事。パーティションキー設計や必要なカラムの絞り込みが上手くできないと10倍から100倍ぐらい負荷が変わる。prestoノード30台、cassandraノード10台で300万件のuser_idを取得してもクエリ自体は3秒ぐらいで終わるし、負荷もかなり軽い。1行辺りのデータ量が増えるとsstableの読み出しに結構な負荷がかかるので、読み込みが詰まる傾向があった。(sstableのキャッシュ)にちゃんとデータを載せておいて、実際のディスクI/Oが発生しない様にしておかないと読み込みが安定しない。セカンダリインデックスについてノード毎にインデックスが作成される、パーティションキーを指定しなくてもクエリ可能になるが、大量のパーティションをスキャンすると異様に遅くなるので、少数のパーティションの中でデータを更に絞り込むのには役に立つが、パーティションキーの代わりに使える様な便利なものではない。データのカーディナリティが低くても高くても駄目で、程々に共通して存在するデータが有効らしい。更新が頻発するカラムだとindex更新に負荷がかかるので、利用を避けるべきです。別途パーティションキーの異なるテーブルを作って、用途に合わせてデータを投入していく方が良さそうです。設定ファイルにseed情報とSnitchの設定を書いて起動すると自動でクラスタに所属します。起動時にbootstrapと呼ばれる処理が走り、自動でデータの再分散が行われます。同時に複数台追加しようとすると、bootstrapが競合するので、追加は1台づつでないと事故ったり止まったりします。急激にクラスタを増強できないので、多少の余裕を見てハンドリングする必要がある。decomissionコマンドを削除したいノードで実行する。データの再分散が行われて完了したらクラスタから情報が削除されます。ノード故障ノードが故障した場合は色々考慮する自体が増えます。handoffという機能により、故障ノードへの書き込み要求をcoordinatorが一時的に受け取ることができます。ノードが復帰したら、hintファイルに蓄積された書き込みデータが同期される。hintが溜まり過ぎるとノードの復帰に時間がかかる。idを渡してノード情報をクラスタから削除する。この時点でhintファイルが溜まっていれば削除されるはずです。ノードを同数に戻す場合は代わりに新しく1台追加します。起動時にJVMオプションを渡して、あるIPのノードを置き換えるという指定をすることで、そのノードの役目を引き継ぐことができる様ですが、オペレーションが複雑化するので諦めて、故障した奴をクラスタから削除し、新規にノードを追加しなおして再分散した方が楽に思える。これはクラスタが持ってるデータ規模等に左右されると思います。seedノード故障seedノードが故障するとめちゃくちゃ面倒なことになる。seedノードは起動時に特別扱いされており、bootstrapが行われない。そのため、一回通常ノードとして構成してbootsrapを完了してからseedノードとして起動しなおすことになる。同一IPで新しくノードを構成しなおそうとすると、非常にややこしいので諦めて新しくノードを追加しbootstrapが終わった時点で、seedにしたいノードのIPを各ノードの設定ファイルに追加し、順番にcassandraを再起動するというのが一番マシな手順ではないかと思います。同じIPで構成しなおしたい場合は、一回seedsリストから除外してcassandraクラスタ全体を再起動した後、ノードを追加してbootstrapが終わった後に、再度seedsリストにIPを追加して、またクラスタ全体を再起動する必要があるようです。クラスタを構成するためにseedノードにかなり依存しているので、ここが本当にややこしい。同時にseedノードが全部死んだ時にどうやって復帰すればいいのかは良く分かっていない。生き残っているノードを新しいseedとして指定した上で、クラスタ全体を再起動し、新しくノードを復活させて設定ファイルをこまごま調整すれば元に戻ると思いますが。今は10数台ぐらいの規模なのでどうってことは無いのですが、これが100台規模になってくるとseedzeノード故障は死ぬ程面倒なのでは、と思うので大規模クラスタ運用している人の知見が欲しい所です。全体的に見て、ノード自体が無事でプロセスが短時間死んだ程度ならどうとでもなりそうですが、ノードごと死ぬとなるとかなりオペレーションが面倒だったり再分散の負荷がかかるので、作業タイミングに注意した方が良さそうです。全体感10台ぐらいで構築するなら、それ程苦労はしなかった。モニタリングもdatadogと組み合わせれば割と簡単にdashboardが構築できました。監視さえしっかりしていれば、落ち着いて運用できそうです。問題はやはりハードウェア故障でノードごと突然死する場合で、そういう場合にデータロストしない様にかつ過剰な負荷がかからない様にオペレーションするのはかなり面倒な気配がビンビンします。書き込みは本当に早いし、スケールするので安心感がある。読み込みはとにかくクエリパターンを事前にちゃんと考えて、それに合わせたパーティション設計をすることが必須です。クエリありきでテーブル構造考えないと、読み込みにめっちゃ負荷がかかることになります。パーティションキーとクエリパターンを中心にしたデータ設計は慣れるまで苦労しそうです。マテビューが入ったことで、クエリパターンに合わせた柔軟なテーブル構成が実現できそうな気配がありますが、実験してみた所書き込みプロセスが不安定になってOOMで落ちたりしたので、もうちょい知見を積むなりリソース調整をマスターする必要がある。後、現時点ではprestoから読み込む対象として利用できないのが、うちの環境だと辛い点でした。ホットデータを利用しやすくしつつスケーラビリティを確保する、という当初の目的は達成できそうなので、しばらく運用を継続して様子を見ていこうと思います。20:14本番環境でcassandraの運用を開始してみたTweet広告を非表示にする2018-06-06Asakusa.rbとは私にとってどんな場所なのかAsakusaの方面から来ました今回、RubyKaigiに来た人は何度かこの画像を目にしたかもしれません。昔からAsakusa.rbに良く参加している人が発表資料を作る時に、良く使われている画像です。シンボリックでアングルが良い写真なので、これが定番として使われています。私とモリスさんも今回のRubyKaigiで使わせてもらいました。最近のAsakusa.rbに良く参加していて、今回のRubyKaigiに登壇していたメンバーは私が覚えている限りで以下の通り。Speakers@tad@284km@youchan全員の資料を見てないので、全ての発表でこの画像が出てたかは分からないですが、めっちゃ多いですね。1日二人以上のペース。正確にはAsakusa.rbは通常のmeetupに一度でも参加したことがある人がメンバーであり、その定義から行くとAsakusa.rbと関係が無いトークの方が少ないレベルですね。参加したことがあるメンバーの居住地がAsakusaと呼ばれるというローカルルールがあります。@unakあたりも含まれそうですね。2018そんなこんなで、Asakusa.rbというコミュニティの存在感がかなり示された結果、懇親会で何度も質問を受けることになりました。「Asakusa.rbって普段どういうことしてるんですか?」と。後、Asakusa.rbがヤバイハッカー集団っぽくて怖いという話も良く聞きますね。質問くれた人には色々と自分が思っていることを話しましたが、なんか需要ありそうだしせっかくのタイミングなので私にとってのAsakusa.rbをブログに書いておくことにしました。Asakusa.rbはmeetupAsakusa.rbは毎週火曜日に、大体神田から上野辺りの範囲で会議室やコミュニティスペースを借りて開かれているmeetupです。ググるとesaの公開ページが出てくるので、そこにメンバー登録して、毎週のmeetupの開催案内に「参加します」とコメントすれば、後は当日にフラっと行くだけです。仕事が忙しい時は参加できなかったり、体調不良だったりする時もあるので、私も常に毎週参加している訳ではないですが、良く参加するメンバーが居たり、たまに参加するメンバーが居たり、色々です。基本的には場所と時間のお知らせだけ書いてあり、テーマはありません。各自、何かやることや話したいこと、相談したいことを適当に持ち込みます。コメントに「今日はgemのメンテやります」とか「資料作成やる予定です」とか書くことが多い。言え、別に何も無くてもブラっと参加して良い会です。毎週時間になったら集まれる場所がある、というのがAsakusa.rbです。meetupとはAsakusa.rbはいわゆる勉強会ではありません。勉強する時間を確保するための場所として使っても全然OKだと思いますが、Rubyに関わることを中心にして人と人が会って話をする場所がAsakusa.rbです。持ち込んだことや最近コード書いてて思ったこと等をベースに、雑談するのがメインと言っても良いでしょう。Asakusaに来る場合は、相談事があると一番入っていきやすいんじゃないかなと思ってます。皆色々教えてくれますし、これ以上ないぐらいに詳しい人から話を聞くチャンスがあります。最近、仕事でこういう問題があったからgem作ってみたんだけどどうですかねーとか、こういう時どうやってデバッグしてるんですかーとか、そういう話があると「オッ」ってなった人が教えてくれたり、それは分からんなー(分からんもんは分からんw)ってなったりします。他の人同士が話している内容でも、自分が興味ありそうなら首を突っ込んで話に混じっていくのが一番楽しめると思います。いう事を切っ掛けに普段からある疑問なり困り事を質問するのも良さそうです。言え、毎週技術の話ばかりをしている訳ではなく、どこかの美味い食事処の話やゲームの話、ガジェットの話をしてたりする時間も良くあります。最近のAsakusa.rbには、主催の松田さんを筆頭にお酒と美味しいご飯が好きなメンバーが大勢居ます。終わった後に飲んで帰りますかーという日もしばしばあります。meetupの終わりが遅いので、22:30ぐらいから飲みに行ったりすることがあります。Asakusa.rbは地域コミュニティなので近所に住んでる人が多く、良い店にあたると終電という概念が存在しなくなるので、そちらにも参加する場合はタイムマネジメントが重要です。他の人の終電を気にする人は余り居ないと思われますwこんな感じでお酒を飲んでワイワイ喋るのが好きな人も多いです。RubyKaigiとAsakusa.rb何故、RubyKaigiでこんなにAsakusa.rbメンバーの登壇者が多いのかというと、メンバーに高いレベルでコードと向き合ってる人が多いというのもあると思いますが、大きな要因は毎週松田さんと会う機会があるという点にあると私は思っています。毎週、松田さんがRubyKaigiのために奔走している姿をチラチラ目にしている中で、CFP出して欲しいという話を毎度聞くことになる訳で、こりゃ是非とも出してKaigiを盛り上げる力になりたいと思う訳です。RubyKaigiがどういう思いを持って運営されているか、どういう発表内容が望まれているかという点について、質問したり聞き易い立場に居ます。技術力という点を抜きにしても、RubyKaigiを楽しんでいく上で恵まれたコミュニティであり、そういう部分が表われているのかなあと思います。(ただ、RubyKaigiのトーク審査は鬼厳しいので、それだけで通る程甘くはない......。)Asakusa.rbは怖い?現時点の私としては全く怖くなくて、ただ単に楽しい集まりなのですが、かつての自分を思い返すと、そういう気持ちも分からなくはないという感じです。私が初めてAsakusa.rbに行ったのはもう4年から5年前ぐらい(良く覚えてない)だと思いますが、初めての頃はちょっとビビりながら参加していたと思います。その感覚をより正確に言うなら「畏れ多い」とかでしょうか。端的に表現すると「怖い」ってなるのは分からなくはない。実際の所、Rubyが好きな人が集まってワイワイ雑談してるのがメインの会であり、本当に怖いことなんか特に何も無い訳です。コードレビューしている訳でもなく、全員が常にRubyをハックしている訳でもないです。私も仕事が終わってなくて普通に仕事しながら回りの雑談を聞いている、みたいな時がよくあります。コードを書いている様に見せかけたり、言い方が悪いかもしれませんが日々の活動がハッタリっぽい人だと話に入っていきづらいかもしれませんが。いう振舞いは嫌いな人が多いと思います。何だかんだでコミュニティって、継続的に参加しているメンバーがいて、ある程度話がしやすい関係性というものが既に構築されている場所です。新しいメンバーを歓迎する工夫があったとしても、やっぱり慣れない集団に参加していこうとするのは勇気が必要な行為だと思います。(特に我々はコミュ力に難のある側の人間なので......)Asakusa.rbに限らず、何度も参加して入れそうな話題に首を突っ込んで、ちょっとづつ慣れていくというのはどこのコミュニティでも必要なことじゃないかと思います。皆Rubyが好きでコードを書くのが好きでそれに関する話をするのも好きだ、という前提があるのでそこを取っ掛かりに話をしやすいのは、どこのRubyコミュニティでも共通のことだと思います。Asakusa.rbももちろんそうです。Asakusa.rbでは新しいメンバーが来ると、全員自己紹介して普段何をしているのかとか今日はこういう話がしたくて来た、という時間を取っています。そこを切っ掛けに声をかけにいくのも良いと思います。その時間は松田さんが来たタイミングで始まるので、たまにその時間がえらく遅くなる時があるのがハードルの一つかもしれないw後、飲み会が不定期でしかも時間がかなり遅いので、そこから交流するのもハードルが高いかもしれない......。Asakusa.rbと海外からのゲスト松田さんを始め、海外カンファレンスで登壇経験があるメンバーも多いので、たまに海外から日本に遊びに来た人がmeetupに参加してくれることがあります。いう時は常に英語って訳ではないですが、英語比率が上がりますし、自己紹介も英語になります。(私は余り上手くないです......)英語が得意でない場合は、初参加のタイミングとしては、ちょっとハードルがあるかもしれません。RubyKaigiで多少なりとも海外から来たRubyistと交流をするための練習としては良い経験が得られると思います。私もじわじわ慣れてきたのかなーという感じです。毎年のRubyKaigiでちょっとづつ海外から来た方と話をする時間を増やすことが出来ているのはAsakusa.rbのおかげもあると思います。ちなみに、Asakusa.rbに海外ゲストが来る時は交流の比率を上げるために、早めの時間から飲み会に移行することが多いですね。Asakusa.rb色々と書かせていただきましたが、これらは私が感じているAsakusa.rbです。これが正しいという訳でも無いですし、回によってイメージが変わることもあります。何度も参加していればきっと楽しくなるし得られるものもあると私は思っていますが、全ての人にとってそうでないこともあるでしょう。私としてはとても楽しい会なので、これからも定期的に参加するつもりだし、新しく色々な人が参加してくれて刺激が得られるのも嬉しいことなので、RubyKaigiやこのエントリ等を通じて興味を持った人がいれば、是非気楽にAsakusa.rbに参加してみてください。Asakusa.rbに限らず、他にも多数存在する地域.rbにも興味があれば是非参加してみてください。それぞれ特色ある集まりです。楽しんで刺激が得られる空間が見つかるかもしれません。仲間が居ると楽しいものだし、ただでさえ最高に楽しいRubyKaigiがもっと楽しくなります。2018に参加してきました。RubyKaigiは毎年最高のイベントなのですが、今年は総合的に今迄で最も良い体験ができたRubyKaigiでした。今回のRubyKaigiで初めてメインスピーカーとして登壇することができました。私が初めてRubyKaigiに参加したのが、確か2011年で1stシーズンのFINALとして開催された時でした。RubyKaigiのメインスピーカーというのは憧れの場であったのですが、7年の歳月を経て辿り着くことができたことを本当に嬉しく思っています。Ruby」というタイトルで話をさせていただきました。@tagomorisさんと二人で発表しました。TracePointやRefinementsやBinding、そしてRubyに存在する様々なフックをこれでもかという程使った内容になっているので、それらの内容に興味がある人には是非資料を見ていただきたいですね。TAGOMORI会場の客足も良くて椅子が足りなくなるぐらいだったし、TLや後の懇親会での評判を聞く限りではかなり楽しんでもらえた様で、自分としても大成功だったと言って良いでしょう。Maedaさんがブログで印象に残った発表として紹介してくれたことです。これはマジでめっちゃ嬉しい。さんにも超感謝しております。さんのkarafkaについての発表は、普段の業務的にも気になる発表で、とても良い話でした。発表後の飲み会で質問が出来たのも良かった。2018また、羽角さんのmruby/cについての発表は内容もさることながら、私としては憧れざるを得ないCOOLさがあって最高でした。RubyKaigiという場所で、私も大好きな日本酒である十旭日の話をするのはカッコ良過ぎですね。実際にmruby/cという新しい技術を使って旭日酒造さんとビジネス事例を生み出しているという点でも凄い話だと思います。2018後、金子さんのASTにカラム情報を入れて正確な位置情報を取れる様にするという仕事は可能性が色々広がりそうで、聞いていて楽しかった。魚介メインで大分美味しいものが食べられた。ホヤ、牡蠣、穴子、どれも美味かった。日本の地方都市開催は多少お金はかかるかもしれないが、めっちゃ楽しめるので素晴らしいと思う。ジョジョを愛して止まない自分としては、この町はRubyKaigiの場所として最高だった。浮かれて3日間、ジョジョTシャツを毎日着てたぐらいです。ちなみに上着はSPW財団のジャケットを着てました。仙台RubyKaigiそのものの経験としても、初スピーカー実績解除できて最高だったし、仙台観光もできて美味しいものも食べれて最高だったし、むかでやで領収書も貰えて最高だった。(語彙)ありがとうRubyKaigi。来年も楽しみにしてます。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。