TOV実況第2回放送舞台裏

舞台裏はトラブルが起こるたびに書かれるのです。
これが書かれているということは・・・察してくれ(´・ω・｀)

前回はしっぽらさんにおだじゅんが操作している画面のシェアができないというトラブルがあり、結局しっぽらさんにはニコニコ動画の配信画面を見てもらいながらテイルズ談義をするという、ほぼ放送事故な状態でした。

今回、同様のトラブルはでなかったので Discord ごしにしっぽらさんはおだじゅんの操作している画面をほぼリアルタイムにみることができたのですが、Discord で話している音声がループして入り続けるという状態に陥りました。さらに、開始してコメントで指摘を受けるまで、おだじゅんの音声は配信されていないという状態。まぁパニックですよね(;ﾟ∀ﾟ)

配信開始前10分程度のやりとりも録画されていたので、また切り出してみました。おだじゅんの音声が入っていないですが、実際はDiscordでみんなとやり取りしています。何を言っているか想像しながら聞いてみてください。前回と同様、おだじゅんとしっぽらさんに加えて、あらさん、つっしーのテイルズ雀士がゲスト参戦しています。

まぁなんとか開始してから数分で状態を改善させることができ、大きなトラブルとなることもなく2回目を終了させることができました。

2回目の内容としては大まかに以下の通り
・花の街ハルルで置いてけぼりカロルくんと改めて合流し「クサッ」で素材集め
・ハルルの樹を治し麗美なアニメーションを拝む
・アスピオでリタと合流し、シャイコス遺跡でリタの名言を拝聴
・エフミドの丘でリタの笑顔の謝罪をめでる

前半は加入したばかりのカロルの言動や仕草、ハルルのアニメーションの話題があり、後半は新しく合流するリタに関する話題が多かったですね。リタの家でエステルが見たものが何なのか知りたい・・・

今回あまり話を広げたり、掘り下げたりすることが前回に比べてできなかったなぁと終わったあとにしっぽらさんとも話していました。まぁ今回出てくる街やダンジョンが、ゲーム以外のメディアであまり舞台として取り上げられていないというのもあり、少し広げにくかったというのも否めません。次回以降はもう少し話を広げていければと思っております。

これでもかというぐらいダウンロードコンテンツでレベルを上げ、戦闘はあまり時間がかからないようにしたつもりですが、それでも時間はかかってしまいました。エフミドの丘を超えたところまで予定してたんですけどね。あっという間に2時間半がすぎてしまった。今度はホーリーボトルも使いつつ、サクサクと話を進めていきたいものです。

視聴してくださった方、コメントしてくださった方、広告してくださった方、皆さん本当にありがとうございます。少しでも楽しんでいただければ幸いです。

次回はみんな大好きガットゥーゾ先生との戦闘から、ラゴウの屋敷あたりを予定しています。パティやおっさんの登場も待ち遠しい。

まえがき

Apache Druid を利用する機会ができたので、まずはドキュメントとか参考資料でインプットを増やしてる。これはその1つの資料として “Druid” A Real-time Analytical Data Store をざっと読んだ際の記録となる

読む目的としては Druid というものがそもそもどういうモチベーションで作られたもので、どういったシチュエーションでパフォーマンスを発揮するものなのか、どういったことが苦手なのかというのを理解すること

資料読メモ

Abstract

Druid とは大規模データセットのリアルタイム探索分析のために設計されたオープンソースのデータストア
カラム指向のストレージレイアウト、分散型のシェアードナッシングアーキテクチャ、先進的なインデックス構造を組み合わせている
10億行のテーブルを1秒以下のレイテンシで任意に探索できるようになっている
この論文では、高速な集約、柔軟なフィルタ、低遅延データインジェストをどのようにサポートしているかを詳細に説明する

1.INTRODUCTION

Hadoop は大量なデータを保存しアクセスすることに優れている。これに対して以下の点に難がある
- どれだけ速くそのデータのアクセスするかについては性能が保証されていない
- 同時実行時の負荷が大きい場合にパフォーマンスが低下する
- データを ingest (データの取得・取り込み)してすぐに読めるようにするためには最適化されていない
同時並行性の高い環境（1000人以上のユーザー）でクエリのパフォーマンスとデータの可用性を製品レベルで保証している企業としては、Hadoopではニーズを満たすことができない
当時のオープンソースでは要件を十分に満たすものがないため、オープンソースの分散型カラム指向リアルタイム分析データストアであるDruidを開発することにした

ここで話されているデータの取得(ingestion)というのは、イベント発生からクエリによって集計できるまでの間を指している

2.PROBLEM DEFINITION

以下の要求を満たす必要がある
- クエリのレイテンシは1秒以内
- マルチテナントで可用性の高いシステム
- 同時進行性の高い環境
- できるだけダウンタイムのない環境
- ユーザーとアラートシステムが「リアルタイム」でビジネス上の意思決定を行えるようにする

3.ARCHITECTURE

Druid は異なるタイプのノードで構成され、異なるノードタイプは互いに独立して動作し、ノード間の相互作用は最小限に抑えられている。これによりクラスタ内の通信障害がデータの可用性に与える影響は最小限になっている
Druid という名前はゲームで出てくる Druidクラス(shape-shifter)に由来する

3.1Real-time Nodes

data ingest とイベントストリームのクエリの機能をカプセル化しており、このノードを経由してインデックス化されたイベントは、すぐにクエリに利用できまる。
小さな時間範囲のイベントのみを扱い、定期的にこの小さな時間範囲で収集したイベントのバッチをDruid クラスタ内の他のノードに渡す。
Druid クラスタとの連携のために Zookeeperを利用しており、Zookeeper にオンライン状態であることと提供するデータについて知らせる
すべての着信イベントのためのインメモリインデックスバッファを保持します。これらのインデックスは、イベントがインジェストされるとインクリメンタルに生成され、インデックスは直接クエリ可能
ヒープオーバーフローの問題を回避するために、定期的に、または最大行数に達した後に、インメモリインデックスをカラム指向のストレージ形式に変換してディスクに永続化する
パーシステッドインデックスをオフヒープメモリにロードして照会できるようにする
定期的にローカルに永続化されたすべてのインデックスを検索するバックグラウンドタスクが走り、インデックスをマージして一定時間に ingect したすべてのイベントを含む不変のデータ・ブロックが作成される。これを segment という
handoff の段階ではこのセグメントを恒久的なバックアップストレージ(S3, HDFS など Druid では deep storage とよんでいるもの)にアップロードする

図3: リアルタイムノードは、イベントをインメモリインデックスにバッファリングし、定期的にディスクに永続化します。定期的に、永続化されたインデックスはマージされてからハンドオフされます。クエリは、インメモリインデックスとパーシステッドインデックスの両方にヒットします。

3.1.1 Availability and Scalability

耐障害性について
- ノードがディスク(データ)を失っていない場合は、ディスクから永続化されたインデックスのリロードをし、オフセットからイベントを読み続けることで復旧可能。回復に必要な時間としても数秒程度。
- 複数のリアルタイムノードがイベントを読み込める単一のエンドポイントとして機能するため、イベントのレプリケーションを作成することと同義。そのため、ノードが完全に故障してディスクを失うシナリオでは、レプリケートされたストリームによってデータが失われることはない
スケールについて
- 複数のリアルタイムノードがそれぞれストリームの一部をインジェストするようにデータストリームを分割することができるので、追加のリアルタイムノードをシームレスに追加することができる。
- 実績として約500MB/s（150,000イベント/sまたは2TB/hour）の生データを消費することが可能

3.2 Historical Nodes

リアルタイムノードによって作成された segment のロードおよび提供する機能をカプセル化している。多くのワークフローにおいてDruidクラスタにロードされるデータの大部分は不変であるため、ヒストリカルノードがDruidクラスタのメインワーカーとなる
ヒストリカルノードは sharednothing アーキテクチャを採用しており、ノード間で競合する単一のポイントは存在しない。機能的には単純で、不変セグメントのロード、ドロップ、サーブのみ。
オンライン状態であることと提供しているデータをZookeeperに通知する。
セグメントのロードとドロップの指示は Zookeeper を介して送信され、セグメントがディープストレージ内のどこにあるか、セグメントを処理する方法などの情報が含まれている。
セグメントに関する情報がキャッシュに存在しない場合、ヒストリカル・ノードは、ディープ・ストレージからセグメントをダウンロードし始める。処理が完了すると、セグメントはZookeeper内で通知され問い合わせ可能となる
ローカルキャッシュを使用することで、履歴ノードを迅速に更新して再起動することができる。起動時に、ノードはキャッシュを検査し、見つけたデータをすぐに利用可能な状態とする。
不変データのみを扱うため、読み取りの一貫性をサポートすることができ、不変データブロックはまた、単純な並列化モデルを可能にする。ヒストリカルノードは、ブロッキングすることなく不変ブロックを同時にスキャンして集約することもできる。

図5: ヒストリカルノードは、ディープストレージからセグメントをダウンロードします。セグメントは、クエリを実行する前にメモリにロードされている必要があります。

3.2.1 Tiers

ヒストリカルノードは異なる階層にグループ化することができ、特定の階層のすべてのノードが同じように構成される。階層ごとに異なるパフォーマンスとフォールトトレランスパラメータを設定できる。
階層化ノードの目的は、優先度の高いセグメントや低いセグメントを重要度に応じて分散できるようにすること

3.2.2 Availability

ヒストリカルノードは、セグメントのロードおよびアンロード命令を Zookeeper に依存しており、Zookeeper が使用できなくなると新しいデータを提供したり、古いデータを削除したりすることができなくなるが、クエリーは HTTP で提供されるため、現在提供しているデータに対するクエリー要求に応答することはできる
Zookeeper の停止がヒストリカルノードの現在のデータ可用性に影響を与えることはないと書いてあるが、0.18.0 のバージョンでは Zookeeper の停止によりDruid も停止となるように修正されている

3.3 Broker Nodes

Broker ノードは、ヒストリカルノードやリアルタイムノードへの問い合わせルータとして動作する
Zookeeper で公開されているメタデータを確認し、どのセグメントがクエリ可能で、そのセグメントがどこにあるかを知る
クエリが適切なヒストリカルノードまたはリアルタイムノードにヒットするように、受信したクエリをルーティングし、ヒストリカルノードとリアルタイムノードからの部分的な結果をマージして、最終的な統合結果を呼び出し元に返す。

3.3.1 Caching

Brokerノードは、LRU [31, 20]の無効化戦略を持つキャッシュを含む。キャッシュはローカルのヒープメモリを使用するか、Memcached [16]のような外部分散型のキー/値ストアを使用することができる
キャッシュに存在しない結果については、ヒストリカルノードとリアルタイムノードにクエリを転送する。ヒストリカルノードが結果を返すと、Broker はこれらの結果をセグメントごとにキャッシュし、将来の使用に備える
リアルタイムデータは永続的に変化しており、結果をキャッシュすることは信頼性がないため、リアルタイムデータは決してキャッシュされない。リアルタイムデータへのリクエストは常にリアルタイムノードに転送されます。
すべてのヒストリカルノードが故障した場合でも、キャッシュに結果が既に存在する場合は結果を返すことができる

3.3.2 Availability

(Zookeeper が死んでも提供できる旨が書かれているが、0.18.0 で Zookeeper と疎通が取れない場合は Druid のプロセスを停止させるようになっているため、このあたりは最新のドキュメントを参考にするのが良さそう)

3.4 Coordinator Nodes

コーディネーターノードは、主にヒストリカルノードでのデータ管理や配信を担当しており、ヒストリカルノードに新しいデータのロード、古いデータのドロップ、データの複製、ロードバランスのためのデータの移動を指示する。
セグメントに新しいセグメントによって最新とは異なったデータが含まれている場合、その古いセグメントはクラスターから削除される。
リーダー選出プロセスを経て、コーディネータ機能を実行する1つのノードを決定し、残りのコーディネータノードは冗長バックアップとして機能する。
コーディネータノードは定期的にクラスタの現在の状態を予想されるクラスタの状態と実行時のクラスタの実際の状態を比較して判断する
現在のクラスタ情報のために Zookeeper 接続をもつ。また、追加の運用パラメータや設定を含む MySQL データベースへの接続ももつ
MySQL データベースにある重要な情報の 1 つは、ヒストリカルノードがサービスを提供するすべてのセグメントのリストを含むテーブル。このテーブルは、リアルタイムノードなど、セグメントを作成するサービスによって更新される。MySQL データベースには、セグメントがクラスタ内でどのように作成、破棄、複製されるかを管理するルールテーブルも含まれている

3.4.1 Rules

ヒストリカルノードのセグメントに対して、どのようにクラスタからロード、ドロップするかを定めたもの。セグメントを異なるヒストリカルノード層にどのように割り当てるか、また、各層にセグメントのレプリケートが何個存在するかも示す
セグメントをクラスタから完全に削除するタイミングを示すこともできる(以下は例)
- 最新の1ヶ月分のセグメントを「ホット」クラスタにロード
- 最新の1年分のセグメントを「コールド」クラスタにロード
- 古いセグメントはすべて削除
コーディネータノードは、MySQLデータベースのルールテーブルからルールのセットをロードする
- ルールは特定のデータソースに固有のものでも、デフォルトのルールセットが設定されていてもよい。コーディネータ・ノードは、利用可能なすべてのセグメントを順番にそのセグメントに適用される最初のルールと一致させる

3.4.2 Load Balancing

クラスタの負荷が過度に不均衡にならないようにセグメントをクラスタ間で分散させる必要がある。クラスタ間でセグメントを最適に分配し、バランスをとるために、セグメントデータのソース、再帰性、サイズを考慮に入れたコストベースの最適化手順を開発した(アルゴリズムについてはここでは話さない)

3.4.3 Replication

異なるヒストリカルノードに同じセグメントのコピーをロードするように指示することができる。高いレベルの耐障害性を必要とする場合、レプリカの数を多く設定することができる。
複製されたセグメントはオリジナルと同じように扱われ、同じ負荷分散アルゴリズムに従う。セグメントを複製することで、単一の履歴ノードの障害はDruidクラスタ内で透過的になり、ソフトウェアのアップグレードなどに利用できる。

3.4.4 Availability

コーディネータノードは、Zookeeper と MySQLと連携している
- Zookeeper ：クラスタ内にどのような履歴ノードが既に存在しているかを判断しており、Zookeeper が利用できなくなると、コーディネーターはセグメントの割り当て、バランス、およびドロップの指示を送信できなくなるが、これらの操作はデータの可用性には全く影響はない
- MySQL：MySQL がダウンした場合、MySQL上のセグメントのメタ情報はコーディネータノードから利用できなくなる。しかしこれはデータ自体が利用できないという意味ではない。コーディネータノードがMySQLと通信できなくなると、新しいセグメントの割り当てを停止し、古くなったセグメントを削除する。ブローカーノード、ヒストリカルノード、およびリアルタイムノードは、MySQL が停止している間も照会可能

4. STORAGE FORMAT

Druidのデータテーブル（データソースと呼ばれる）は、タイムスタンプの付いたイベントの集合体であり、セグメントのセットに分割され、各セグメントは通常500万～1,000万行になる。正式には、セグメントをある期間に渡るデータの行の集合体と定義する。セグメントはDruidの基本的なストレージユニットを表し、レプリケーションと配布はセグメントレベルで行われる
データ分配ポリシー、データ保持ポリシー、および第一レベルのクエリ・プルーニングを簡素化する方法として、常にタイムスタンプ・カラムを必要としている
データソースを明確に定義された時間間隔（一般的には1時間または1日）に分割し、さらに他の列の値を分割して、希望のセグメントサイズに収めることができる
セグメントは、データソースの識別子、データの時間間隔、新しいセグメントが作成されるたびに増加するバージョン文字列によって一意に定まる
バージョン文字列はセグメントデータの新しさを示し、バージョンが古いセグメントよりも、バージョンが新しいセグメントの方が（ある時間範囲内で）新しいデータであることを示す
セグメントはカラムナーベースで保存される
LZF [24] 圧縮アルゴリズムを基本的には使用

4.1 Indices for Filtering Data

Druidは、特定のクエリ・フィルタに関連する行のみがスキャンされるように、文字列列用の追加のルックアップ・インデックスを作成する
Druid ではビットマップ圧縮アルゴリズムとしてConciseアルゴリズム[10]を使用することを選択した

4.2 Storage Engine

Druidのパーシステンスコンポーネントでは、異なるストレージエンジンを接続することができる
これらのストレージエンジンは、JVMヒープのような完全なインメモリ構造でデータを保存したり、メモリマップされた構造でデータを保存したりする
デフォルトでは、メモリマップされたストレージエンジンが使用されるが、パフォーマンスが必要な場合は、高価ではあるがインメモリ・ストレージ・エンジンを使用することもできる
メモリマップド・ストレージ・エンジンを使用する場合、Druid はセグメントをメモリの中に入れたり出したりする際にオペレーティング・システムに依存する
メモリマップ型ストレージエンジンを使用した場合の主な欠点は、クエリの実行時に、あるノードの容量を超えて多くのセグメントをメモリにページする必要がある場合、セグメントをメモリ内でページングしたり、メモリ外でページングしたりするためのコストに悩まされる点

5. QUERY API

Druidは独自のクエリ言語を持ち、POSTリクエストとしてクエリを受け付ける。ブローカー、ヒストリカル、リアルタイムノードはすべて同じクエリAPIを共有している。
POSTリクエストの本文は、様々なクエリパラメータを指定したkey-valueペアを含むJSONオブジェクト。典型的なクエリには、データソース名、結果データの粒度、対象の時間範囲、リクエストのタイプ、集約するメトリクスが含まれ、結果は期間にわたって集約されたメトリクスを含む JSON オブジェクトになる
執筆当初、Druid用の結合クエリはまだ実装されていない(0.18.0 で実装された)。組織にとって実装コストは投資に見合うものではないという選択をしたため

6. PERFORMANCE

2014年初頭の時点でMetamarketsで運用されているメインの運用クラスタの数値
他のデータベースとの比較のために、TPC-Hデータ上での合成ワークロードの結果も掲載

6.1 Query Performance in Production

Druidクエリのパフォーマンスは、発行されるクエリによって大きく変化する
実運用のDruidクラスタにおけるクエリの平均レイテンシを示すために、最もクエリされたデータソースの中から8つを選択し計測した
パフォーマンス
- クエリの平均レイテンシは約550ミリ秒
- 90%のクエリが1秒未満で返されている
- 95%のクエリが2秒未満で返されている
- 99%のクエリが10秒未満で返されている

6.2 Query Benchmarks on TPC-H Data

Druid のほうが断然速いという内容以外特に特筆することはなし
MySQL側の実行エンジンとして MyISAMを使用してたのは気になる(執筆当時はまだあるが、2020-04 だと InnoDBが主流)

6.3 Data Ingestion Performance

Druidのデータインジェストのレイテンシは、インジェストされるデータセットの複雑さに大きく依存する。データの複雑さは、各イベントに含まれるディメンジョンの数、各イベントに含まれるメトリクスの数、およびそれらのメトリクスで実行したい集計の種類によって決まる。
最も基本的なデータセット（タイムスタンプ列のみを持つデータセット）では、800,000イベント/秒/コアの速度でデータをインジェストできますが、現実のデータセットは決してこれほど単純ではない。
スループットを、リアルタイムノードがインジェストし、クエリ可能なイベントの数と定義
あまりにも多くのイベントがリアルタイムノードに送られた場合、リアルタイムノードがそれらのイベントを受け入れる余裕ができるまで、それらのイベントはブロックされる。本番環境で測定したピークインジェストレイテンシは、Amazon cc2.8xlarge インスタンスを実行している30のディメンションと19のメトリクスを持つデータソースで22914.43イベント/秒/コア

7. DRUID IN PRODUCTION

QueryPattern
- 探索的なユースケースでは、1人のユーザーが発行するクエリの数は多くなる。
- 探索的なクエリでは、結果を絞り込むために同じ時間範囲のフィルタを段階的に追加することがよくあり、最近のデータの短い時間間隔を探索する傾向がある。
- レポートを生成するユースケースでは、ユーザーはより長いデータ間隔でクエリを行うが、これらのクエリは一般的に数が少ない
Multitenancy
- 負荷の高い同時実行クエリは、マルチテナントでは問題となりえる。
- 負荷の高いクエリにより実行できないクエリが出ることへの対応として、クエリの優先順位付けを導入した。
- 各ヒストリカルノードは、スキャンする必要のあるセグメントに優先順位をつけることができる
- かなりの量のデータに対するクエリは、レポーティングのユースケースのためのものである傾向があり、優先順位を下げることができる。このユースケースでは、データを探索するときと同じレベルのインタラクティブ性をユーザーは期待していない
Node Failures
- ヒストリカルノードが完全に失敗して回復しない場合は、セグメントを再割り当てする必要がある。これはつまり、このデータをロードするためには余力が必要になる。
- 経験から、2つ以上のノードが一度に完全に故障することは非常に稀であり、2つのヒストリカルノードからのデータを完全に再割り当てできるだけの余力をクラスタに残している
Data Center Outage
- 完全なクラスタ停止はありえるが、非常にまれ。
- 完全停止した場合、ディープストレージがまだ利用可能である限り、過去のノードがディープストレージからすべてのセグメントを再ダウンロードするだけで済むため、クラスタのリカバリ時間はネットワークに依存する
- 過去の障害では、Amazon AWSのエコシステムで数テラバイトのデータに対して数時間のリカバリータイムが発生した

7.1 Operational Monitoring

各Druidノードは、定期的に一連の運用メトリクスを出力するように設計されている
- CPU使用率
- 使用可能なメモリ
- ディスク容量
- ガベージコレクション時間
- ヒープ使用率
- セグメントスキャン時間
- キャッシュヒット率
- データインジェストレイテンシ
- クエリごとのメトリクス

7.2 Pairing Druid with a Stream Processor

Druidは完全に非正規化されたデータストリームしか使用できない
本番環境で完全なビジネスロジックを提供するために、DruidはApache Storm [27]のようなストリームプロセッサとペアにすることができる

7.3 Multiple Data Center Distribution

大規模な停止は、単一ノードだけでなく、データセンター全体にも影響を及ぼす可能性がある
Druid コーディネーターノードのティア構成では、セグメントを複数のティアにまたがってレプリケートすることができる。そのため、セグメントは複数のデータセンターにあるヒストリカルノード間で正確に複製することができる。
クエリの優先順位を異なる階層に割り当てることができる
あるデータセンターのノードをプライマリクラスタとして動作させ別のデータセンターに冗長クラスタを設置することも可能

以下全文日本語訳

1.INTRODUCTION

近年、インターネット技術の普及により、機械が生成するイベントが急増している。これらのイベントは個々には有用な情報がほとんど含まれておらず、価値が低い。大規模なイベントのコレクションから意味を抽出するのに必要な時間とリソースを考えると、多くの企業はこのようなデータを破棄することになります。イベントベースのデータを扱うためのインフラストラクチャは構築されているが（IBMのNetezza[37]、HPのVertica[5]、EMCのGreenplum[29]など）、それらは大部分が高価格で販売されており、余裕のある企業のみを対象としている。数年前、GoogleはMapReduce [11]を同社の汎用ハードウェアを活用してインターネットのインデックスを作成し、ログを分析する仕組み。Hadoop [36] プロジェクトがすぐに続きから出てきた洞察を主にパターン化したものです。MapReduceの論文。Hadoopは現在、大量のログデータを保存・分析するために多くの組織に導入されています。[…] は、価値の低いイベントストリームを、ビジネスインテリジェンスやA-Bテストなどのさまざまなアプリケーションのための価値の高いアグリゲートに変換する企業を支援することに多くの貢献をしてきました。 Hadoopは、企業が価値の低いイベントストリームを、ビジネスインテリジェンスやA-Bテストなどのさまざまなアプリケーションのための価値の高いアグリゲートに変換するのに多くの貢献をしてきました。

多くの優れたシステムと同様に、Hadoopは新たな問題に目を向けさせてくれました。具体的には、Hadoopは大量のデータを保存し、アクセスを提供することに優れていますが、そのデータにどれだけ素早くアクセスできるかについては、パフォーマンスが保証されていません。さらに、Hadoop は可用性の高いシステムではありますが、同時実行時の負荷が大きい場合にはパフォーマンスが低下します。最後に、Hadoop はデータの保存には適していますが、データをインジェストしてそのデータをすぐに読めるようにするためには最適化されていません。Metamarkets製品の開発の初期段階で、これらの問題に直面し、Hadoopは優れたバックオフィス、バッチ処理、データウェアハウスシステムであることに気付きました。しかし、同時並行性の高い環境（1000人以上のユーザー）でクエリのパフォーマンスとデータの可用性を製品レベルで保証している企業としては、Hadoopは私たちのニーズを満たすことができませんでした。この分野のさまざまなソリューションを検討し、リレーショナルデータベース管理システムとNoSQLアーキテクチャの両方を試した結果、オープンソースの世界には、当社の要件を十分に活用できるものはないという結論に達しました。結局、オープンソースの分散型カラム指向リアルタイム分析データストアであるDruidを開発することになりました。多くの点で、Druidは他のOLAPシステム[30, 35, 22]、対話型クエリシステム[28]、メインメモリデータベース[14]やとして広く知られている分散データストア[7, 12, 23]。
分散型やクエリモデルは現時点の検索インフラからアイデアを借りています。[25, 3, 4]。

この論文では、Druid のアーキテクチャについて説明し、ホストされたサービスに電力を供給する(?)常時稼働型の生産システムを作成する際に行われた様々な設計上の決定事項を探り、同様の問題に直面している人に、解決の可能性のある方法についての情報を提供することを試みています。Druidは、複数のテクノロジー企業で本番さながらに展開されています. 本稿の構成は以下の通りである。セクション2で問題について説明し、次に、システムアーキテクチャについて、データがどのようにシステムを流れるかという観点から詳細について話す。次に、データがバイナリに変換される方法と理由について説明します。セクション4でフォーマットを説明し、クエリAPIについてはセクション5で簡単に説明し、性能結果をセクション6で紹介する．最後にセクション7では、本番でDruidを運用していた時の教訓を交えながら第8節に関連研究を示す。

2.PROBLEM DEFINITION

Druidは元々、大量のトランザクションイベント（ログデータ）をインジェストして探索する問題を解決するために設計されました。
この形式の時系列データは、OLAPワークフローで一般的に見られ、データの性質上、非常に重い追加処理が必要になる傾向があります。次のような場合に使用します。例として、表1に示すデータを考えてみましょう。表1にはウィキペディア上で発生した編集の情報が含まれています。ユーザーが編集するたびにメタデータを含むイベントが生成されます。このメタデータは3つの異なるコンポーネントで構成されています。第一に、編集された時間の timestamp。次に、編集されたページや編集を行ったユーザーと、そのユーザーの場所といったカラムのセット。最後に編集により追加・削除された文字数といったメトリクス郡(通常は数値)

私たちの目標は、このデータのドリルダウンや集計を迅速に計算することです。サンフランシスコの男性からJustin Bieberのページに何回編集が行われたか」や「カルガリーの人が1ヶ月間に追加した平均文字数は何文字か」といった質問に答えたいと考えています。また、任意の任意のディメンションの組み合わせに対するクエリは、1秒以内のレイテンシーで返すようにしたい。

Druidの必要性は、既存のオープンな RDBMS と NoSQLのキー/値ストアがインタラクティブなアプリケーションに対して低レイテンシでのデータ取得とクエリプラットフォームを提供できなかったことにより促進された[40]。ダッシュボードを支えるデータ・ストアは、その上に構築されたデータ・ビジュアライゼーションがユーザーにインタラクティブな体験を提供できるように、十分な速さでクエリを返す必要がありました。

クエリのレイテンシーのニーズに加えて、マルチテナントで可用性の高いシステムである必要がありました。Metamarkets製品は、高度に同時進行性の高い環境で使用されています。ダウンタイムにはコストがかかり、多くの企業はソフトウェアのアップグレードやネットワーク障害に直面してシステムが利用できなくなった場合、待っている余裕はありません。適切な社内運用管理を行っていないことが多い新興企業のダウンタイムは、ビジネスの成否を左右する可能性があります。

最後に、メタマーケッツが初期に直面したもう一つの課題は、ユーザーとアラートシステムが「リアルタイム」でビジネス上の意思決定を行えるようにすることでした。イベントが作成されてから、そのイベントがクエリ可能な状態になるまでの時間は、関心のある関係者がシステム内の潜在的に破滅的な状況にどれだけ早く対応できるかを決定します。Hadoopのような人気のあるオープンソースのデータウェアハウスシステムでは、私たちが必要とするサブセコンドのデータ取り込みレイテンシを提供することができませんでした。

データの探索、取り込み、可用性の問題は、複数の業界にまたがる。Druidは2012年10月にオープンソース化されて以来、ビデオ、ネットワーク監視、運用監視、オンライン広告分析プラットフォームとして複数の企業に導入されています。

3.ARCHITECTURE

Druidクラスタは異なるタイプのノードで構成され、各ノードタイプは特定のセットを実行するように設計されています。この設計は、懸念事項を分離し、システム全体の複雑さを単純化すると考えています。異なるノードタイプは互いに独立して動作し、ノード間の相互作用は最小限に抑えられています。したがって、クラスタ内の通信障害がデータの可用性に与える影響は最小限に抑えられています。

複雑なデータ分析の問題を解決するために、異なるノードタイプが一緒になって完全に動作するシステムを形成します。Druidという名前は、多くのロールプレイングゲームに登場するDruidクラスに由来しています。これはシェイプシフターで、グループ内で様々な役割を果たすために多くの異なる形態を取ることができます。
Druidクラスタ内のデータの構成と流れを図1に示します。

3.1Real-time Nodes

リアルタイムノードは、インジェストとイベントストリームのクエリの機能をカプセル化しています。これらのノードを経由してインデックス化されたイベントは、すぐにクエリに利用できます。ノードは小さな時間範囲のイベントのみを扱い、定期的にこの小さな時間範囲で収集した不変イベントのバッチを、不変イベントのバッチを扱うことに特化した Druid クラスタ内の他のノードに渡します。リアルタイムノードは、残りの Druid クラスタとの連携のために Zookeeper [19] を利用する。ノードは Zookeeper にオンライン状態であることと提供するデータについて知らせる

リアルタイムノードは、すべての着信イベントのためのインメモリインデックスバッファを保持します。これらのインデックスは、イベントがインジェストされるとインクリメンタルに生成され、インデックスは直接クエリ可能です。Druidは、このJVMヒープベースのバッファに存在するイベントに対するクエリのための行ストアとして動作します。ヒープオーバーフローの問題を回避するために、リアルタイムノードは、定期的に、または最大行数に達した後に、インメモリインデックスをディスクに永続化します。このパーシストプロセスは、インメモリバッファに格納されたデータをセクション4で説明したカラム指向のストレージ形式に変換します。各パーシステッドインデックスは不変であり、リアルタイムノードはパーシステッドインデックスをオフヒープメモリにロードして、まだ照会できるようにします。このプロセスは[33]で詳しく説明されており、図2に示されています。

図2:ノードは起動し、データをインジェストし、永続化し、定期的にデータを渡します。このプロセスは無期限に繰り返されます。異なるリアルタイム・ノード操作の間の期間は、構成可能です。

定期的に、各リアルタイムノードはローカルに永続化されたすべてのインデックスを検索するバックグラウンドタスクをスケジュールします。このタスクは、これらのインデックスをマージして、リアルタイム・ノードがある時間の間に摂取したすべてのイベントを含む不変のデータ・ブロックを構築します。このデータブロックを「セグメント」と呼びます。ハンドオフの段階では、リアルタイムノードはこのセグメントを恒久的なバックアップストレージ、一般的にはS3 [12]やHDFS [36]などの分散ファイルシステムにアップロードします。インジェスト、パーシスト、マージ、およびハンドオフの各段階は流動的です。

図３は、リアルタイムノードの動作を示す図である。ノードは13:37に開始し、現在の1時間(13時台)、あるいは次の1時間(14時台)のイベントのみを受け入れます。イベントがインジェストされると、ノードは13:00から14:00までの間隔でデータのセグメントを提供していることを知らせる。10分ごと（持続時間は設定可能）に、ノードはそのインメモリバッファをフラッシュしてディスクに持続させます。1時間の終わり近くになると、ノードは14:00～15:00のイベントを見ることになるでしょう。これが発生すると、ノードは次の時間のデータを提供する準備をし、新しいインメモリインデックスを作成します。その後、ノードは14:00から15:00までのセグメントも提供していることを知らせる。ノードは、13:00から14:00までの永続インデックスをすぐにマージするのではなく、13:00から14:00までのイベントが到着するまで、構成可能なウィンドウ期間を待ちます。このウィンドウ期間は、イベント配信の遅延によるデータ損失のリスクを最小限に抑えます。ウィンドウ期間の終了時に、ノードは13:00から14:00までのすべての永続インデックスを1つの不変セグメントにマージし、セグメントを渡します。このセグメントがロードされ、Druidクラスタ内のどこか他の場所でクエリ可能になると、リアルタイムノードは13:00～14:00の間に収集したデータに関するすべての情報をフラッシュし、このデータを提供していることを知らせないようになる。

3.1.1 Availability and Scalability

リアルタイムノードはデータの消費者であり、データストリームを提供するために対応するプロデューサを必要とします。一般的に、データの耐久性を目的として、図4に示すように、Kafka [21]のようなメッセージバスがプロデューサーとリアルタイムノードの間に配置されています。リアルタイムノードは、メッセージバスからイベントを読み取ることによってデータをインジェストする。イベント作成からイベント消費までの時間は通常数百ミリ秒のオーダーです。

図4:複数のリアルタイムノードが同じメッセージバスから読み出すことができます。各ノードは独自のオフセットを維持します。

図４のメッセージバスの目的は２つある。第一に、メッセージバスは受信イベントのバッファとして機能します。Kafka のようなメッセージバスは、コンシューマ(リアルタイムノード)がイベントストリームの中でどれだけの距離を読んだかを示す位置オフセットを保持しています。コンシューマはこれらのオフセットをプログラムで更新することができます。リアルタイムノードは、メモリ内のバッファをディスクに永続化するたびに、このオフセットを更新します。フェイルアンドリカバリーのシナリオでは、ノードがディスクを失っていない場合、ディスクからすべての永続化されたインデックスをリロードして、最後にコミットしたオフセットからイベントを読み続けることができます。最近コミットしたオフセットからイベントを取り込むことで、ノードのリカバリ時間が大幅に短縮されます。実際には、ノードがこのような障害シナリオから数秒で回復するのを確認している。

メッセージバスの第二の目的は、複数のリアルタイムノードがイベントを読み込める単一のエンドポイントとして機能することです。複数のリアルタイムノードは、バスから同じイベントセットをインジェストし、イベントのレプリケーションを作成することができます。ノードが完全に故障してディスクを失うシナリオでは、レプリケートされたストリームによってデータが失われることはありません。また、単一のインジェストエンドポイントにより、複数のリアルタイムノードがそれぞれストリームの一部をインジェストするようにデータストリームを分割することができます。これにより、追加のリアルタイムノードをシームレスに追加することができます。実際には、このモデルにより、最大規模のプロダクションDruidクラスタでは、約500MB/s（150,000イベント/sまたは2TB/hour）の生データを消費することが可能になりました。

3.2 Historical Nodes

ヒストリカルノードは、リアルタイムノードによって作成されたデータの不変ブロック（セグメント）のロードおよび提供する機能をカプセル化しています。多くの実世界のワークフローでは、Druidクラスタにロードされるデータの大部分は不変であるため、ヒストリカルノードがDruidクラスタのメインワーカーとなります。ヒストリカルノードはsharednothingアーキテクチャを採用しており、ノード間で競合する単一のポイントは存在しません。ノードはお互いの知識を持たず、操作的には単純で、不変セグメントのロード、ドロップ、サーブの方法を知っているだけです。

リアルタイムノードと同様に、ヒストリカルノードは、そのオンライン状態と提供しているデータをZookeeperに通知する。セグメントのロードとドロップの指示は Zookeeper を介して送信され、セグメントがディープストレージ内のどこにあるか、セグメントを解凍して処理する方法などの情報が含まれています。ヒストリカルノードは、ディープストレージから特定のセグメントをダウンロードする前に、まず、ノードに既に存在するセグメントの情報を保持するローカルキャッシュをチェックします。セグメントに関する情報がキャッシュに存在しない場合、ヒストリカル・ノードは、ディープ・ストレージからセグメントをダウンロードし始める。この処理を図5に示す。処理が完了すると、セグメントはZookeeper内で通知される。この時点で、セグメントは問い合わせ可能です。また、ローカルキャッシュを使用することで、履歴ノードを迅速に更新して再起動することができます。起動時に、ノードはキャッシュを検査し、見つけたデータをすぐに提供します。

図5: ヒストリカルノードは、ディープストレージから不変のセグメントをダウンロードします。セグメントは、クエリを実行する前にメモリにロードされている必要があります。

ヒストリカルノードは不変データのみを扱うため、読み取りの一貫性をサポートすることができます。不変データブロックはまた、単純な並列化モデルを可能にします。ヒストリカルノードは、ブロッキングすることなく、不変ブロックを同時にスキャンして集約することができます。

3.2.1 Tiers

ヒストリカルノードは異なる階層にグループ化することができ、特定の階層のすべてのノードが同じように構成されます。階層ごとに異なるパフォーマンスとフォールトトレランスパラメータを設定できます。階層化ノードの目的は、優先度の高いセグメントや低いセグメントを重要度に応じて分散できるようにすることです。例えば、コア数が多く、メモリ容量が大きい履歴ノードの「ホット」ティアをスピンアップすることが可能です。「ホット」クラスタは、より頻繁にアクセスされるデータをダウンロードするように構成することができます。並列の「コールド」クラスタは、性能の低いバッキングハードウェアを使用して作成することもできます。コールド」クラスタには、アクセス頻度の低いセグメントのみが含まれます。

3.2.2 AVAILABILITY

履歴ノードは、セグメントのロードおよびアンロード命令を Zookeeper に依存しています。Zookeeper が使用できなくなると、ヒストリカルノードは新しいデータを提供したり、古いデータを削除したりすることができなくなりますが、クエリーは HTTP で提供されるため、ヒストリカルノードは現在提供しているデータに対するクエリー要求に応答することができます。つまり、Zookeeper の停止がヒストリカルノードの現在のデータ可用性に影響を与えることはありません。

3.3 Broker Nodes

Broker ノードは、ヒストリカルノードやリアルタイムノードへの問い合わせルータとして動作します。Broker ノードは、Zookeeper で公開されているメタデータを確認し、どのセグメントがクエリ可能で、そのセグメントがどこにあるかを知る。Broker ノードは、クエリが適切なヒストリカルノードまたはリアルタイムノードにヒットするように、受信したクエリをルーティングします。また、Broker ノードは、ヒストリカルノードとリアルタイムノードからの部分的な結果をマージして、最終的な統合結果を呼び出し元に返す。

3.3.1 CACHING

Brokerノードは、LRU [31, 20]の無効化戦略を持つキャッシュを含む。キャッシュはローカルのヒープメモリを使用するか、Memcached [16]のような外部分散型のキー/値ストアを使用することができる。特定のセグメントの結果はすでにキャッシュに存在している可能性があり、再計算の必要はありません。キャッシュに存在しない結果については、ブローカー・ノードが正しいヒストリカルノードとリアルタイムノードにクエリを転送します。ヒストリカルノードが結果を返すと、ブローカはこれらの結果をセグメントごとにキャッシュし、将来の使用に備えます。このプロセスを図6に示します。リアルタイムデータは決してキャッシュされないため、リアルタイムデータへのリクエストは常にリアルタイムノードに転送されます。リアルタイムデータは永続的に変化しており、結果をキャッシュすることは信頼性がありません。

キャッシュは、データ耐久性の追加レベルとしても機能します。すべての履歴ノードが故障した場合でも、キャッシュに結果が既に存在する場合は結果を照会することができます。

図6:結果はセグメントごとにキャッシュされます。クエリは、キャッシュされた結果と、ヒストリカルノードおよびリアルタイムノードで計算された結果を組み合わせます。

3.3.2 AVAILABILITY

Zookeeper が完全に停止した場合でも、データは照会可能である。ブローカーノードが Zookeeper と通信できない場合は、最後に知っているクラスタのビューを使用し、リアルタイムノードとヒストリカルノードにクエリを転送し続けます。ブローカーノードは、クラスタの構造が停止前と同じであることを前提としている。実際には、この可用性モデルにより、Zookeeper の停止を診断している間、Druid クラスタはかなりの期間、クエリを提供し続けることができました。

3.4 Coordinator Nodes

ドルイドのコーディネーターノードは、主にヒストリカルノードでのデータ管理や配信を担当しています。コーディネーターノードは、ヒストリカルノードに新しいデータのロード、古いデータのドロップ、データの複製、ロードバランスのためのデータの移動を指示します。Druidは、安定したビューを維持するために、不変セグメントを管理するためにマルチバージョン同時実行制御スワッピングプロトコルを使用しています。不変セグメントに新しいセグメントによって完全に時代遅れになったデータが含まれている場合、その時代遅れのセグメントはクラスターから削除されます。不変セグメントに新しいセグメントによって完全に時代遅れになったデータが含まれている場合、その時代遅れのセグメントはクラスターから削除されます。コーディネータノードはリーダー選出プロセスを経て、コーディネータ機能を実行する1つのノードを決定します。残りのコーディネータノードは冗長バックアップとして機能します。

コーディネータノードは定期的に実行され、クラスタの現在の状態を判断します。コーディネータノードは、予想されるクラスタの状態と、実行時のクラスタの実際の状態を比較して判断します。他の Druid ノードと同様に、コーディネータノードは現在のクラスタ情報のために Zookeeper 接続を維持します。コーディネータ・ノードはまた、追加の運用パラメータや設定を含む MySQL データベースへの接続を維持します。MySQL データベースにある重要な情報の 1 つは、履歴ノードがサービスを提供すべきすべてのセグメントのリストを含むテーブルです。このテーブルは、リアルタイムノードなど、セグメントを作成するサービスによって更新することができます。MySQL データベースには、セグメントがクラスタ内でどのように作成、破棄、複製されるかを管理するルールテーブルも含まれています。

3.4.1 Rules

ヒストリカルセグメントをどのようにクラスタからロード、ドロップするかのルールが与えられる。ルールは、セグメントを異なるヒストリカルノード層にどのように割り当てるか、また、各層にセグメントのレプリケートが何個存在するかを示します。ルールはまた、セグメントをクラスタから完全に削除するタイミングを示すこともできます。ルールは通常、一定期間設定されます。例えば、ユーザーはルールを使用して、最新の1ヶ月分のセグメントを「ホット」クラスタにロードし、最新の1年分のセグメントを「コールド」クラスタにロードし、古いセグメントはすべて削除することができます。

コーディネータノードは、MySQLデータベースのルールテーブルからルールのセットをロードします。ルールは、特定のデータソースに固有のものであってもよいし、デフォルトのルールセットが設定されていてもよい。コーディネータ・ノードは、利用可能なすべてのセグメントを循環させ、各セグメントをそのセグメントに適用される最初のルールと一致させます。

3.4.2 LOAD BALANCING

典型的な本番環境では、クエリは数十、あるいは数百のセグメントにヒットすることがよくあります。各ヒストリカルノードのリソースは限られているため、クラスタの負荷が過度に不均衡にならないようにセグメントをクラスタ間で分散させる必要があります。最適な負荷分散を決定するには、クエリのパターンと速度に関する知識が必要です。一般的に、クエリは単一のデータソースの連続する時間間隔にまたがる最近のセグメントをカバーしています。平均的には、より小さなセグメントにアクセスするクエリの方が高速です。

これらのクエリパターンは、最近(直近１周間など)のヒストリカルセグメントをより高い割合で複製し、異なるヒストリカルノードにある時間的に近い大きなセグメントを分散させ、異なるデータソースからセグメントを同じ場所に配置するということを示している。クラスタ間でセグメントを最適に分配し、バランスをとるために、セグメントデータのソース、再帰性、サイズを考慮に入れたコストベースの最適化手順を開発した。アルゴリズムの正確な詳細は本論文の範囲を超えており、将来の文献で議論される可能性がある。

3.4.3 REPLICATION

コーディネータノードは、異なるヒストリカルノードに同じセグメントのコピーをロードするように指示することができます。ヒストリカルコンピュートクラスタの各層のレプリカの数は、完全に設定可能です。高いレベルの耐障害性を必要とするセットアップでは、レプリカの数を多く設定することができます。複製されたセグメントはオリジナルと同じように扱われ、同じ負荷分散アルゴリズムに従います。セグメントを複製することで、単一の履歴ノードの障害はDruidクラスタ内で透過的になります。私たちはこの特性をソフトウェアのアップグレードに利用しています。シームレスにヒストリカルノードをオフラインにして、それを更新して、それを復活させ、クラスタ内のすべてのヒストリカルノードに対してこのプロセスを繰り返すことができます。過去2年間、ソフトウェア・アップグレードのためにDruidクラスタでダウンタイムを取ったことは一度もありません。

3.4.4 AVAILABILITY

Druid コーディネータノードは、Zookeeper と MySQL を外部依存関係として持っています。コーディネータノードは Zookeeper に依存して、クラスタ内にどのような履歴ノードが既に存在しているかを判断します。Zookeeper が利用できなくなると、コーディネーターはセグメントの割り当て、バランス、およびドロップの指示を送信できなくなります。ただし、これらの操作はデータの可用性には全く影響しません。

MySQLとZookeeperの障害に対応するための設計原理は同じ。連携を担当する外部依存関係が失敗した場合、クラスタは現状を維持します。DruidはMySQLを使用して、運用管理情報と、クラスタ内に存在すべきセグメントに関するセグメントメタデータ情報を保存します。MySQLがダウンした場合、この情報はコーディネータノードから利用できなくなります。しかし、これはデータ自体が利用できないという意味ではありません。コーディネータノードがMySQLと通信できなくなると、新しいセグメントの割り当てを停止し、古くなったセグメントを削除します。ブローカーノード、ヒストリカルノード、およびリアルタイムノードは、MySQL が停止している間も照会可能です。

4. STORAGE FORMAT

Druidのデータテーブル（データソースと呼ばれる）は、タイムスタンプの付いたイベントの集合体であり、セグメントのセットに分割されており、各セグメントは通常500万～1,000万行になります。正式には、セグメントをある期間に渡るデータの行の集合体と定義します。セグメントはDruidの基本的なストレージユニットを表し、レプリケーションと配布はセグメントレベルで行われます。

Druidは、データ分配ポリシー、データ保持ポリシー、および第一レベルのクエリ・プルーニングを簡素化する方法として、常にタイムスタンプ・カラムを必要としています。Druidは、データソースを明確に定義された時間間隔（一般的には1時間または1日）に分割し、さらに他の列の値を分割して、希望のセグメントサイズを達成することができます。セグメントを分割する時間の粒度は、データ量と時間範囲の関数です。1年に渡るタイムスタンプを持つデータセットは1日単位で、1日に渡るタイムスタンプを持つデータセットは1時間単位で分割するのが良いでしょう。

セグメントは、データソースの識別子、データの時間間隔、新しいセグメントが作成されるたびに増加するバージョン文字列によって一意に定まる。バージョン文字列は、セグメントデータの新しさを示します。バージョンが古いセグメントよりも、バージョンが後のセグメントの方が（ある時間範囲内で）新しいデータを表示します。読み込み操作は常に、特定の時間範囲のデータに、その時間範囲の最新のバージョン識別子を持つセグメントからアクセスします。

Druidのセグメントは、カラム志向で保存されます。Druidがイベントストリームの集約に最適であることを考えると（Druidに入るすべてのデータはタイムスタンプを持っていなければなりません）、集約情報を行ではなく列として保存することの利点は十分に文書化されています[1]。列ストレージでは、必要なものだけを実際にロードしてスキャンするため、CPUの使用効率が向上します。行指向のデータストアでは、行に関連付けられたすべての列が集約の一部としてスキャンされなければなりません。追加のスキャン時間は、以下のような重大なパフォーマンスの低下をもたらす可能性があります。

Druidには、様々なデータ形式を表現するための複数のカラムタイプがあります。カラムの種類に応じて、メモリやディスクにカラムを格納するコストを削減するために、さまざまな圧縮方法が使用されます。表1の例では、ページ、ユーザー、性別、および都市の列は文字列のみを含んでいます。文字列を直接格納することは不必要にコストがかかるため、文字列の列は代わりに辞書エンコードすることができます。辞書エンコーディングはデータを圧縮するための一般的な方法であり、PowerDrill [17]のような他のデータストアでも使用されています。

このマッピングにより、ページ列を整数の配列として表現することができ、配列のインデックスは元のデータセットの行に対応します。ページ列については、以下のように一意なページを表現することができます。結果として得られる整数配列は，それ自体が圧縮方式に非常に適しています．エンコーディングの上にある一般的な圧縮アルゴリズムは，カラムストアでは非常に一般的です．Druid は LZF [24] 圧縮アルゴリズムを使用しています。同様の圧縮方法を数値列にも適用することができます。例えば、表1の追加された文字と削除された文字の列は、個々の配列として表現することもできます。この場合、辞書表現とは対照的に生の値を圧縮します。

4.1 Indices for Filtering Data

多くの現実のOLAPワークフローでは、クエリは、ディメンジョン指定のセットが満たされているメトリクスセットの集約された結果に対して発行されます。例えば、”サンフランシスコの男性ユーザーがウィキペディアの編集を行った数は？” このクエリは、ディメンション値のブール式に基づいて、表1のWikipediaデータセットをフィルタリングする。多くの実世界のデータセットでは、ディメンジョンの列には文字列が含まれ、メトリックの列には数値が含まれています。Druidは、特定のクエリ・フィルタに関連する行のみがスキャンされるように、文字列列用の追加のルックアップ・インデックスを作成します。

表1のページ欄を考えてみましょう。表1の各ユニークなページについて、特定のページがどの表の行で見られるかを示す何らかの表現を形成することができます。この情報は，配列のインデックスが行を表すバイナリ配列に格納することができます．特定のページが特定の行にある場合、その配列インデックスは1とマークされます。(Table1 の例で)ジャスティン・ビーバーは0行目と1行目に見られる。この列の値と行のインデックスの対応付けは、転置インデックスを形成する[39]。Justin BieberとKe$haのどちらの行が含まれているかを知るには、2つの配列をORすることができます。

大きなビットマップに対してブール演算を実行するアプローチセットは検索エンジンでよく使われています。OLAPのためのビットマップインデックスワークロードについては、[32]で詳しく説明しています。ビットマップ圧縮アルゴリズムは、よく定義された研究分野であり[2, 44, 42]、多くの場合、実行長エンコーディングを利用します。DruidはConciseアルゴリズム[10]を使用することを選択しました。図7は、整数配列を使用した場合とConcise圧縮を使用した場合のバイト数を示しています。結果はcc2.8xlargeシステム上で生成され、シングルスレッド、2Gヒープ、512mのヤングジェン、各実行間に強制GCを使用しました。データセットは、Twitter garden hose [41]のデータストリームから収集した1日分のデータです。データセットには、2,272,295行、様々なカーディナリティの12次元が含まれています。追加の比較として、我々はまた、圧縮を最大化するためにデータセットの行をリゾートしました

ソートされていないケースでは、Conciseの合計サイズは53,451,144バイト、整数配列の合計サイズは127,248,520バイトでした。全体として、Concise圧縮セットは整数配列よりも約42%小さくなっています。ソートされたケースでは、Concise圧縮の合計サイズは43,832,884バイト、整数配列の合計サイズは127,248,520バイトでした。興味深いのは、ソート後、グローバル圧縮は最小限にしか増加しなかったことです。

4.2 Storage Engine

Druidのパーシステンスコンポーネントでは、Dynamo [12]と同様に、異なるストレージエンジンを接続することができます。これらのストレージエンジンは、JVMヒープのような完全なインメモリ構造でデータを保存したり、メモリマップされた構造でデータを保存したりします。ストレージエンジンをスワップする機能により、特定のアプリケーションの仕様に応じて Druid を構成することができます。インメモリ・ストレージ・エンジンは、メモリ・マップド・ストレージ・エンジンよりも運用上高価ですが、パフォーマンスが重要な場合には、より良い代替手段となります。デフォルトでは、メモリマップされたストレージエンジンが使用されます。

メモリマップド・ストレージ・エンジンを使用する場合、Druid はセグメントをメモリの中に入れたり出したりする際にオペレーティング・システムに依存します。セグメントはメモリにロードされていないとスキャンできないことを考えると、メモリマップされたストレージエンジンを使用することで、最近のセグメントはメモリに保持され、クエリーされなかったセグメントはページアウトされることになります。メモリマップ型ストレージエンジンを使用した場合の主な欠点は、クエリの実行時に、あるノードの容量を超えて多くのセグメントをメモリにページする必要がある場合です。この場合、クエリのパフォーマンスは、セグメントをメモリ内でページングしたり、メモリ外でページングしたりするためのコストに悩まされます。

5. QUERY API

Druidは独自のクエリ言語を持ち、POSTリクエストとしてクエリを受け付けます。ブローカー、ヒストリカル、リアルタイムノードはすべて同じクエリAPIを共有しています。

POSTリクエストの本文は、様々なクエリパラメータを指定したkey-valueペアを含むJSONオブジェクトです。典型的なクエリには、データソース名、結果データの粒度、関心のある時間範囲、リクエストのタイプ、集約するメトリクスが含まれます。結果は、期間にわたって集約されたメトリクスを含む JSON オブジェクトにもなります。

ほとんどの問い合わせタイプはフィルタセットもサポートしています。フィルタ・セットは、ディメンジョン名と値のペアのブール演算式です。ディメンジョンと値の任意の数および組み合わせを指定できます。フィルタ・セットが提供されると、フィルタ・セットに関連するデータのサブセットのみがスキャンされます。複雑な入れ子になったフィルタセットを扱うことができるため、Druidは任意の深さのデータを掘り下げることができます。

正確なクエリ構文は、クエリの種類と要求された情報によって異なります。1週間のデータを対象としたサンプルカウントクエリは以下のようになります。

{
 "queryType" : "timeseries",
 "dataSource" : "wikipedia",
 "intervals" : "2013-01-01/2013-01-08",
 "filter" : {
              "type" : "selector",
              "dimension" : "page",
              "value" : "Ke$ha"
            },
 "granularity" : "day",
 "aggregations" : [{"type":"count", "name":"rows"}] 
}

上記のクエリは、2013-01-01から2013-01-08までのWikipediaデータソース内の行数のカウントを返しますが、”page “ディメンジョンの値が “Ke$ha “に等しい行のみにフィルタリングされています。結果は日ごとにバケット化され、以下の形式のJSON配列となる。

 [ {
     "timestamp": "2012-01-01T00:00:00.000Z",
     "result": {"rows":393298}
 },
 {
     "timestamp": "2012-01-02T00:00:00.000Z",
     "result": {"rows":382932}
 },
 ...
 {
     "timestamp": "2012-01-07T00:00:00.000Z",
     "result": {"rows": 1337}
 } ]

Druidは、浮動小数点型や整数型の和、最小値、最大値、そしてカーディナリティ推定や近似分位推定などの複雑な集計を含む多くのタイプの集計をサポートしています。集約の結果は，他の集計を形成するために数式で組み合わせることができる．クエリAPIについて完全に説明することはこの論文の範囲を超えていますが、より多くの情報はオンラインで見ることができます。

この記事を書いている時点では、Druid用の結合クエリはまだ実装されていません。これは、エンジニアリングリソースの割り当てと技術的なメリットに基づいて決定されるよりも、ケースの決定に基づいて決定されます。確かに、Druidのストレージ形式では、結合の実装が可能になります（ディメンジョンとして含まれる列の忠実度が損なわれることはありません）し、その実装は数ヶ月に一度の会話になっています。これまでのところ、私たちの組織にとって実装コストは投資に見合うものではないという選択をしてきました。この決定の理由は、一般的には2つあります。

ジョインクエリのスケーリングは、私たちの専門的な経験では、分散データベースでの作業のボトルネックとなっています。
機能の増分は、同時進行性の高い、結合負荷の高いワークロードを管理する際に予想される問題よりも価値が低いと考えられます。

結合クエリとは、基本的には、2つ以上のデータに基づいて、共有されたキーのセットに基づいて結合クエリを実行します。私たちが知っている結合クエリの主な高レベル戦略は、ハッシュベースの戦略かソートされたマージ戦略です。ハッシュベースの戦略では、1つのデータセット以外のすべてのデータセットがハッシュテーブルのように見えるものとして利用可能であることが必要で、検索操作は「プライマリ」ストリームのすべての行に対してこのハッシュテーブルに対して実行されます。ソートマージ戦略は、各ストリームが結合キーでソートされていることを前提としているため、ストリームのインクリメンタルな結合が可能です。しかし、これらの戦略のそれぞれは、ソートされた順番かハッシュテーブル形式のいずれかで、いくつかのストリームを実体化する必要があります。

結合のすべての側面が非常に大きなテーブル（10億レコード以上）である場合、事前結合ストリームを実現するには、複雑な分散メモリ管理が必要になります。メモリ管理の複雑さは、高度に同時進行するマルチテナントのワークロードを対象としているという事実によってのみ増幅されます。これは、私たちが知る限りでは、学術的に活発な研究課題であり、スケーラブルな方法で解決することに貢献したいと考えています。

6. PERFORMANCE

Druidはいくつかの組織で運用されていますが、そのパフォーマンスを実証するために、2014年初頭の時点でMetamarketsで運用されているメインの運用クラスタの実世界の数値を共有することにしました。他のデータベースとの比較のために、TPC-Hデータ上での合成ワークロードの結果も掲載しています。

6.1 Query Performance in Production

Druidクエリのパフォーマンスは、発行されるクエリによって大きく変化します。例えば、与えられたメトリックに基づいて高カーディナリティディメンジョンの値をソートすることは、時間範囲内の単純なカウントよりもはるかに高価です。実運用のDruidクラスタにおけるクエリの平均レイテンシを示すために、表2に記載されているように、最もクエリされたデータソースの中から8つを選択しました。

クエリの約30%は異なるタイプのメトリクスやフィルタを含む標準的な集約であり、クエリの60%は集約された1つ以上のディメンション上でグループごとに順序付けられており、クエリの10%は検索クエリとメタデータ検索クエリである。アグリゲートクエリでスキャンされるカラム数は、ほぼ指数関数的な分布に従います。単一のカラムを含むクエリは非常に頻繁に発生し、すべてのカラムを含むクエリは非常にまれです。

結果についてのいくつかの注意事項。

結果は、私たちのプロダクション・クラスタの「ホット」ティアからのものです。この結果は、当社の生産クラスタ内の「ホット」層での結果です。階層には約 50 のデータソースがあり、数百人のユーザーがクエリを発行していました。
ホット」なティアと約10TBのセグメントをロードしています。合わせて。このティアには約500億のDruidの列があります。すべてのデータソースは表示されません。
ホットティアはインテル® Xeon® E5-2670 プロセッサーを使用しており、以下の構成になっています。1302個の処理スレッドと672個の総コア(ハイパースレッド)で構成されています。
メモリマップされたストレージエンジンが使用されました(マシンはにデータをロードするのではなく、メモリマップするように設定されています。Javaヒープ)。

クエリのレイテンシを図 8 に、1 分間あたりのクエリを図 9 に示す。さまざまなデータソースすべてにおいて、クエリの平均レイテンシは約550ミリ秒で、90%のクエリが1秒未満、95%のクエリが2秒未満、99%のクエリが10秒未満で返されています。2月19日に観測されたように、Memcachedインスタンスのネットワークの問題が、最大のデータソースの1つであるクエリの負荷が非常に高くなることで複合的に発生したように、レイテンシが急増することもあります。

図8: Query latencies of production data sources.

図9: Queries per minute of production data sources.

6.2 Query Benchmarks on TPC-H Data

また、TPC-Hのデータでドルイドのベンチマークを紹介しています。ほとんどのTPC-HクエリはDruidに直接適用されないため、クエリのパフォーマンスを示すために、Druidのワークロードに典型的なクエリを選択しました。比較として、MyISAMエンジンを使用してMySQLを使用した同じクエリの結果も提供しています（我々の実験ではInnoDBの方が遅かった）。

ベンチマークの対象として MySQL を選択したのは、その普遍的な人気の高さからです。他のオープンソースのカラムストアを選択しないことにしたのは、最適なパフォーマンスを得るために正しくチューニングできる自信がなかったからです。

Druidのセットアップでは、ヒストリカルノードにAmazon EC2のm3.2xlargeインスタンスタイプ（Intel® Xeon® E5-2680 v2 @ 2.80GHz）を、ブローカーノードにはc3.2xlargeインスタンス（Intel® Xeon® E5-2670 v2 @ 2.50GHz）を使用しました。MySQL のセットアップは、同じ m3.2xlarge インスタンスタイプで動作する Amazon RDS インスタンスでした。

1GBのTPC-Hデータセットの結果を図10に、100GBのデータセットの結果を図11に示す。Druidのスキャンレートを、与えられた時間間隔でのselect count(*)等価クエリの場合は53,539,211行/秒/コア、select sum(float)型クエリの場合は36,246,530行/秒/コアでベンチマークしました。

最後に、TPC-H 100GBのデータセットを用いて、増加するデータ量に対応するためにDruidをスケーリングした結果を紹介します。図12に示すように、コア数を8コアから48コアに増やした場合、すべてのタイプのクエリが線形スケーリングを達成するわけではありませんが、よりシンプルなアグリゲーションクエリでは線形スケーリングが達成されていることがわかります。

並列コンピューティングシステムの高速化は、システムの逐次処理に必要な時間によって制限されることが多い。この場合、ブローカレベルで相当量の作業を必要とするクエリは、同様に並列化されません。

6.3 Data Ingestion Performance

Druidのデータインジェストのレイテンシを示すために、ディメンション、メトリクス、イベントボリュームが異なる複数の本番用データソースを選択しました。本番環境でのインジェスト・セットアップは、6 ノード、合計 360GB の RAM、96 コア（12 x Intel®Xeon®E5-2670）で構成されています。

このセットアップでは、複数の他のデータソースがインジェストされ、他の多くのDruid関連のインジェストタスクがマシン上で同時に実行されていたことに注意してください。

Druidのデータインジェストのレイテンシは、インジェストされるデータセットの複雑さに大きく依存します。データの複雑さは、各イベントに含まれるディメンジョンの数、各イベントに含まれるメトリクスの数、およびそれらのメトリクスで実行したい集計の種類によって決まります。最も基本的なデータセット（タイムスタンプ列のみを持つデータセット）では、私たちのセットアップでは800,000イベント/秒/コアの速度でデータをインジェストできますが、これはイベントをデシリアライズする速度の測定に過ぎません。現実のデータセットは決してこれほど単純ではありません。表3は、データソースの選択とその特性を示しています。

表3の記述に基づいて、レイテンシは大きく変化し、インジェストレイテンシは必ずしもディメンションとメトリクスの数の要因ではないことがわかります。単純なデータ・セットでは、データ・プロデューサーがデータを配信していたレートであったため、いくつかの低いレイテンシが見られます。その結果を図13に示す。

スループットを、リアルタイムノードがインジェストし、クエリ可能なイベントの数と定義します。あまりにも多くのイベントがリアルタイムノードに送られた場合、リアルタイムノードがそれらのイベントを受け入れる容量があるまで、それらのイベントはブロックされます。本番環境で測定したピークインジェストレイテンシは、Amazon cc2.8xlarge インスタンスを実行している30のディメンションと19のメトリクスを持つデータソースで22914.43イベント/秒/コアでした。

我々が提示した待ち時間の測定値は、インタラクティブ性の問題を解決するのに十分なものです。我々は、待ち時間の変動が少ない方が良いと考えています。ハードウェアを追加することでレイテンシを減らすことはまだ可能ですが、インフラのコストがまだ考慮されているため、そうすることを選択していません。

7. DRUID IN PRODUCTION

ここ数年の間に、私たちはドルイドでの生産ワークロードの処理について多大な知識を得ており、いくつかの興味深い観察を行ってきました。

QueryPattaen

Druidは、データの探索やデータのレポート生成によく使われます。探索的なユースケースでは、1人のユーザーが発行するクエリの数は、報告的なユースケースよりもはるかに多くなります。探索的なクエリでは、結果を絞り込むために同じ時間範囲のフィルタを段階的に追加することがよくあります。ユーザーは、最近のデータの短い時間間隔を探索する傾向があります。レポートを生成するユースケースでは、ユーザーはより長いデータ間隔でクエリを行いますが、これらのクエリは一般的に数が少なく、事前に決定されています。

Multitenancy

負荷の高い同時実行クエリは、マルチテナントでは問題となりえる。大規模なデータソースに対するクエリは、クラスタ内のすべてのヒストリカルノードにヒットしてしまい、すべてのクラスタリソースを消費してしまう可能性があります。このような場合、より小さくて安価なクエリは実行がブロックされてしまう可能性があります。このような問題に対処するために、クエリの優先順位付けを導入しました。各ヒストリカルノードは、スキャンする必要のあるセグメントに優先順位をつけることができます。適切なクエリのプランニングは、本番のワークロードにとって非常に重要です。ありがたいことに、かなりの量のデータに対するクエリは、レポーティングのユースケースのためのものである傾向があり、優先順位を下げることができます。ユーザーは、このユースケースでは、データを探索するときと同じレベルのインタラクティブ性を期待していません。

Node failures.

シングルノードの障害は分散環境では一般的ですが一度に多くのノードが故障した場合はそうではありません。ヒストリカルノードが完全に失敗して回復しない場合は、セグメントを再割り当てする必要があります。つまり、このデータをロードするためには過剰なクラスタ容量が必要です。いつでも追加できるキャパシティの量は、クラスタの運用コストに貢献します。私たちの経験から、2つ以上のノードが一度に完全に故障することは非常に稀であり、したがって、私たちは2つの履歴ノードからのデータを完全に再割り当てできるだけの十分な容量をクラスタに残しています。

Data Center Outages.

完全なクラスタ停止はありえるが、非常にまれです。Druidが単一のデータセンターにしか導入されていない場合、データセンター全体で障害が発生する可能性があります。そのような場合、新しいマシンをプロビジョニングする必要があります。ディープストレージがまだ利用可能である限り、過去のノードがディープストレージからすべてのセグメントを再ダウンロードするだけで済むため、クラスタのリカバリ時間はネットワークに依存します。過去にもこのような障害を経験しており、Amazon AWSのエコシステムでは数テラバイトのデータに対して数時間のリカバリータイムが発生していました。

7.1 Operational Monitoring

大規模な分散型クラスタを運用するためには、適切なモニタリングが重要です。各Druidノードは、定期的に一連の運用メトリクスを出力するように設計されています。これらのメトリクスには、CPU使用率、使用可能なメモリ、ディスク容量などのシステムレベルのデータ、ガベージコレクション時間、ヒープ使用率などのJVM統計、セグメントスキャン時間、キャッシュヒット率、データインジェストレイテンシなどのノード固有のメトリクスが含まれます。Druidはまた、クエリごとのメトリクスを出力します。

本番の Druid クラスタからメトリクスを放出し、それをメトリクス Druidクラスタにロードします。本番クラスタの性能と安定性を探るために、メトリクスDruidクラスタを使用しています。この専用のメトリクス・クラスタを使用することで、クエリ速度の段階的な低下、最適にチューニングされていないハードウェア、その他の様々なシステム・ボトルネックなど、多数の本番環境の問題を発見することができました。また、本番環境でどのようなクエリがなげられているのか、どのようなデータの側面にユーザが興味を持っているのかを分析するために、メトリクス・クラスタを使用しています。

7.2 Pairing Druid with a Stream Processor

現在のところ、Druidは完全に非正規化されたデータストリームしか理解できません。本番環境で完全なビジネスロジックを提供するために、DruidはApache Storm [27]のようなストリームプロセッサとペアにすることができます。

ストームトポロジーは、データストリームからイベントを消費し、「オンタイム」のイベントのみを保持し、関連するビジネスロジックを適用します。これには、id から名前のルックアップなどの単純な変換から、複数ストリームの結合などの複雑な操作までが含まれます。ストームのトポロジーは、処理されたイベントストリームをリアルタイムでドルイドに転送します。ストームはストリーミングデータの処理作業を処理し、Druidはリアルタイムデータとヒストリカルデータの両方のクエリへの応答に使用されます。

7.3 Multiple Data Center Distribution

大規模な生産停止は、単一ノードだけでなく、データセンター全体にも影響を及ぼす可能性があります。Druid コーディネーターノードのティア構成では、セグメントを複数のティアにまたがってレプリケートすることができます。そのため、セグメントは複数のデータセンターにあるヒストリカルノード間で正確に複製することができます。同様に、クエリの優先順位を異なる階層に割り当てることができます。あるデータセンターのノードをプライマリクラスタとして動作させ（すべてのクエリを受信）、別のデータセンターに冗長クラスタを設置することも可能です。このようなセットアップは、1つのデータセンターがユーザーにかなり近い場所にある場合に必要になるかもしれません。

TOV実況第1回放送舞台裏

「テイルズ談義をひたすらする場がほしいね」

そんな一言から、ゲーム実況しながらテイルズ談義してはどうかという企画が上がり約一ヶ月。1回目の放送が実施されました。以下は配信のアーカイブ動画になります。

会話がもたないのではないかと始まる前はかな～り心配ではありましたが、終わってみれば何も話さないといった時間帯は特になく、かなり楽しくしっぽらさんとやりとりしながら配信できた。

Twitterで宣伝してくれた方、見に来てくれた方、コメントしてくれた方、広告してくれた方、皆さん本当にありがとうございますm(_ _)m

戦闘がかなりヒヤヒヤとする場面が多かったのは予想外ではあったが(汗)
次からは戦闘サクサクやるためにレベル上げとくかな。

実は配信を始める1時間前からしっぽらさんと準備をしていたのですが、当初予定していた配信環境ではうまく配信できないことがわかり、急遽配信環境を変更したというやり取りがありました。

予定していた環境としては、自分がプレイしている映像をしっぽらさんはDiscordのGoLiveという配信映像を見ながらDiscordで通話するという状態を想定していました。直前になってしっぽらさんのほうで映像が見れないというトラブルが発生してんやわんや。別の日に確認したときは問題とかなかったんやけどなぁ。。。

結局しっぽらさんはニコニコ動画の配信動画を見ながら話すという環境になっていましたが、特にこの状態が問題となることもなかったようでひと安心。今後環境が整いしっぽらさんの方でも遅延なしに映像が見られるようになるとええんやけども(；・∀・)

放送開始直前のドタバタがそれはそれで面白くて、録画していた動画にその部分も含まれていたのでここにおいておきます。特にOPを見ている最中の「ジュディスの足が出てる」といったしっぽらさんの発言あたりは仲間内でツボにはまりました。自分としっぽらさん以外に、テイルズ雀士として切磋琢磨しているつっしー、あらさんの音声も入っています(動画出力におけるトラブルで音ズレが発生しています)

次回は4/26(日)を予定しております。エフミドの丘を超えるところまで行ければなとおもっておりますがどうなることやら。

ここまで見ていただきありがとうございます。また次回も見ていただけると嬉しいです。みんなでテイルズについて語り明かそう！！ ᕦ(ò_óˇ)ᕤ“

統計検定準1級出題範囲差分確認

コロナで色々なイベントが中止・延期となっているなかで、6月に実施予定の統計検定は、自分が受験予定の統計検定準1級のみが実施予定というアナウンスが出されました。年に1度しか機会がないものではありますが、もしも中止となったらそれはそれで、11月実施予定の1級に的を絞って勉強するのもいいかなと思っていたりしたので、複雑な気持ちでいます。

2020年6月以降の統計検定準1級出題範囲について、新しくPDFが提供されています。今までのものと比較してパッと見ただけでは差分が分かりづらいですが、以下の項目が追加されています。

大項目	小項目	項目(学習しておくべき用語)例
回帰分析	その他	ニューラルネットワークモデル
多変量解析	判別分析	ROC, AUC, 混合行列

以前の範囲から削除された項目はなく、学習範囲が拡大されただけ。範囲変更直後の試験では、この追加された項目はほぼ確実に出ると思うので、取りこぼしのないようにしたいところです。

ニューラルネットワークモデル

機械学習に精通していない方でもこの言葉自体は何らかのメディアで聞いたことがあるかと思います。知名度が高くなった(基本的な知識として認知され始めた)という背景を受け、追加された項目であろうとおもいます。1級の出題範囲にも含まれておらず、公式の参考書にもこの言葉は見受けられないので、独自に参考書なり探して知識をつけておく必要があるでしょう。

ROC曲線, AUC(c統計量)

医学生物分野における検査精度に関する項目。こちらは1級の範囲にもともとあったものが、準1級の範囲にも移されたというものになります。1級対応の公式参考書には書かれているので、1級対応の公式参考書の内容を見ておくと良いでしょう。この2つの項目は例として出されているだけなので、検査精度に関する項目全体について目を通しておくことが必要かもしれません。

日本統計学会公式認定統計検定1級対応統計学

混合行列

パターン認識などの分野で用いられるモデルの真偽出力と実際の真偽値とをテーブルの形式で表したものになります。検定の第一種過誤・第二種過誤の項目で用いるテーブルと考え方としては同じですが、異なる表現をしていることがあるため、検定のことなのか判別分析のことなのかを意識してキーワードを覚える必要があります。

” 第一種過誤と第二種過誤” フリー百科事典『ウィキペディア（Wikipedia）』より　
最終更新 2019年12月14日 (土) 08:15 UTC

” Confusion matrix” Wikipedia, the free encyclopedia より
31 March 2020, at 18:00 (UTC)

荒野のコトブキ飛行隊大争奪戦の戦い方

荒野のコトブキ飛行隊で新しく実装された同盟同士の戦闘システム「大争奪戦」

今回のイベントはなんといっても情報量が多く、すべてのテキストを読むのを諦め、始まってから考えるというのを選んだプレイヤーも多いのではなかろうか。

このページでは、1回目の前哨戦を踏まえ、大争奪戦ではどのように戦うかについて考察する。あくまで個人的な考察なので正しくないこともかいている可能性があることはご了承ください

前提

考察するにあたり以下の状態を前提として話をすすめる。これらに沿わない状況の場合は参考程度に見ていただければと思います。

所属同盟には25～30名が所属しておりその9割ほどがアクティブアカウント
対戦相手となる他の2同盟が結託していない
同盟内のやり取りはゲーム中の掲示板のみ

結論

テキスト読むのしんどいよという方向けに、個人的な戦い方の結論を先に箇条書きにしておくので、ここだけ読んでもらっても大丈夫です。このように考えた経緯も知りたいという方はそのまま読み進めてください。

イベント終了2時間前からはできるだけ自同盟内でコミュニケーション取れる状態を保つ
できるだけAPは60の状態を保ち柔軟に行動できるようにしておく
イベント終了1時間前までに、相手同盟の防衛拠点までの経路となる、相手中継拠点をいつでも落とせる状態にする(1編隊だけをわざと倒さない状態にする)
イベント終了1時間前以降に防衛拠点を落とす
イベント終了30分以降に中継拠点を落とす
防衛拠点有利色より中継拠点有利色を優先して編成を組む
相手同盟の中継拠点と隣接する自同盟の中継拠点に積極的に編成配置をする(NPCをできるだけ戦わせない)
相手同盟の中継拠点を攻めるときは自同盟中継拠点が２つ隣接しているところから攻める
終盤までは1位にならず2つの相手同盟から狙い撃ちにされないようにする

荒野のコトブキ飛行隊　Blu-ray BOX(上下巻セット/発売日順次お届け)

大争奪戦の争奪ポイントについて整理

他のイベントに比べ説明テキストの量が多く、加えて実際に試さないと不明であった点もあるため改めて大争奪戦の勝利条件となる争奪ポイントについて整理する

勝利条件について

3同盟と争う大争奪戦は争奪ポイントによって同盟の順位が決められる。この争奪ポイントが変動するタイミングは以下の2つある。

プレイヤーの行動による争奪ポイントの加算
拠点獲得による争奪ポイントの移動

この2種の争奪ポイントで相手同盟を上回ることができれば見事1位を獲得することができる。1. のポイントは都合よくいけば90,000ポイント得ることはでき、ここまで獲得することは非常に困難であるものの、自同盟からの攻撃で8割勝つようにいどめば50,000ポイントは十分に狙える

また、拠点獲得による争奪ポイントはすべての拠点を確保した場合、初期ポイントに加えて76,000ポイント獲得できる。この内半分以上(4,0000ポイント)を4つの防衛拠点のポイントが占めるため、防衛拠点を確保した状態でいかにしてゲーム終了に持ち込むかというのが戦略のポイントとなる

プレイヤーの行動による争奪ポイントについて

プレイヤーの行動による争奪ポイントは、以下のような3種のポイントが合算されたもの

自同盟のAP消費の行動により獲得できるポイントは多くて約63,000ポイント
自同盟の編成配置により獲得できるポイントは最大で750ポイント
相手同盟の行動により獲得できるポイントは多くて約30,000ポイント

相手同盟の行動については制御ができないため、自同盟のAP消費による行動でできるだけ負けないように振る舞うというのがセオリーになってくるだろう。同盟内で強いプレイヤーは、相手同盟の中でも強い相手をできるだけ倒し、他のメンバーが倒しやすい相手を残してあげることで、同盟全体の争奪ポイントの向上が見込める

以下は数値の根拠であるが、未確認の部分もあるため正しい数値と異なるかもしれません

1プレイヤーあたり獲得できるAPは最大210, 30名で6,300AP
　初期値30 + 6時間毎に30 × 6回(36時間) = 210AP

1つの相手同盟の中継拠点を確保するために最低限60AP必要として、すべての敵相手同盟の中継拠点(24箇所)を確保するために1440AP必要
1つの相手同盟の防衛拠点を確保するために最低限10AP必要として、すべての相手同盟の防衛拠点(4箇所)を確保するために40AP必要

40APで相手同盟のすべての防衛拠点を確保した場合に獲得できる争奪ポイント
(100ポイント + 60(撃墜数) × 2) × 4 = 880ポイント

残りのAPを使用し、すべての攻撃で勝利した場合に獲得できる争奪ポイント
6260AP ÷ 10(1回あたりの消費AP) × 100ポイント = 62,600ポイント

相手同盟からの攻撃に対して、すべて相手が敗北となった場合
6300AP × 2チーム ÷ 10(1回あたりの消費AP) × 30ポイント = 37800ポイント
ただし、自同盟の攻撃がすべて勝利とするためには、相手同盟に中継拠点を取り返してもらわないと攻撃対象がなくなるため、相手同盟の攻撃がすべて敗北となることはありえない

一度確保した相手同盟の防衛拠点を相手同盟に取り返され、再度取り返す場合に加算される撃墜数によるポイントは複雑になるため今は考えない

自同盟で配置が可能な編成数
  30人 × 5編成 = 150編成
すべての相手同盟の中継拠点、防衛拠点に配置可能な編成数
  24中継拠点 × 6編成 = 144編成
  4防衛拠点 × 7編成 = 28編成
すべての相手同盟の中継拠点、防衛拠点に配置することは不可なので、
配置により獲得できるポイントの最大値は
  150編成 × 5ポイント = 750ポイント

NPCの自動配置によりポイントが発生しないものとしている
配置の変更のたびにポイントが発生しないものとしている

拠点獲得による争奪ポイントの移動について

プレイヤーの行動によって得られる争奪ポイントの加算とは異なり、相手同盟拠点の確保はポイントの移動となるため、相手の争奪ポイントを減らす事ができる。また、1拠点あたりのポイント変動が大きいため、ゲーム終了時にどのように拠点を確保した状態にするかが重要になる

特に、防衛拠点は1つで6中継拠点を超える点数が移動するため、相手同盟の防衛拠点を、ゲーム終了時にいかにして確保するかが大争奪戦の大きなポイントとなる

仮に、相手同盟のすべての拠点を確保できた場合のポイントは76,000ポイントとなる

24中継拠点 × 1,500ポイント = 36,000ポイント
4防衛拠点 × 10,000ポイント = 40,000ポイント

イベント終了2時間前は張りつけ！

イベント終了時の拠点の状態がポイントに大きく関わるため、終了間際が最も攻防が激しくなるタイミングとなる。できるだけ同盟内でコミュニケーションを取れる状態としておくことが望ましい。ここで注意しておきたいのは、防衛拠点と中継拠点の確保タイミングと自同盟内の残りAPとなる。

防衛拠点確保はイベント終了1時間前以降

10,000ポイントが変動する防衛拠点は、イベント終了時には1つでも多く確保した状態でイベント終了を迎えたい。そのためには、イベント終了間際に相手同盟が防衛拠点を攻撃できない状態にすればよい。防衛拠点のステータスの中で、相手同盟からの攻撃を受けない時間帯「準備中」があるので、これを最大限利用する。

防衛拠点を確保したあと1時間は準備中のステータスとなり、相手同盟からの攻撃を受け付けない状態となる

イベント終了の1時間前以降(前哨戦1の場合3/15 23時以降)に確保することができれば、防衛拠点は確実に確保した同盟のものとなる

ちなみに、自同盟が確保した防衛拠点に隣接する中継拠点すべてを相手同盟に確保されたとしても、防衛拠点は自同盟が確保した状態のままなので、防衛拠点周囲の中継拠点を確保し続ける必要はない

同様に、中継拠点も確保したあと30分の準備中ステータスがあり相手同盟からの攻撃は受けないので、イベント終了の30分前以降(前哨戦1の場合3/15 23時半以降)に確保することで確実にポイントに繋げられる

当然、相手同盟も同様のことを狙ってくるはずなので、防衛拠点に隣接する中継拠点、防衛拠点までの経路は重要な攻撃・防衛のポイントになる

相手中継拠点をいつでも落とせる状態でキープ

1つでも空域を奪われた中継拠点は「争奪中」のステータスとなり、防衛編隊の配置ができなくなります。特に時間制限もないため、防衛側は確保されてしまうまで手が出せなくなります。

これを利用し、相手同盟の防衛拠点までの経路となる相手同盟の中継拠点を、イベント終了1時間半前(前哨戦1の場合3/15 22時半)ごろまで残り1編隊の状態で維持して、いつでも落とせるという状態を作り出します。そしてイベント終了1時間半前に中継拠点、イベント終了1時間前に防衛拠点と立て続けに確保することが狙えます。

ただし注意点として、争奪中の相手同盟中継拠点に隣接する中継地点がすべて相手同盟に確保されてしまった場合、争奪中のステータがなくなり回復してしまうので、あまり長い間争奪中の状態にするのもAPの無駄打ちになりかねません。

相手同盟の中継地点を争奪中のステータスにした場合は、その周囲の中継地点の動向にも気を配る必要があります。右図の例でいうと中継C2を黄色が確保すると中継C5の争奪中のステータスがなくなり回復した状態になります

AP60の状態を保つ

イベント終了間際2時間ぐらいは上記のような中継拠点、防衛拠点の奪い合いが激しい状態となります。相手の出方次第でとるべき戦略も変わるので、できるだけ行動できる回数を多く残しておきたいです。特に終盤は、APは60の状態をできるだけ保つようにしておき、取れる選択肢が多い状態を保つことをおすすめします。

終盤で自同盟のAPが充分に残っており手数で圧倒できるという状態であれば、防衛拠点の確保も難しくはないでしょう。

中継拠点有利色を優先して編成を組む

編成において悩まされるポイントとしては、中継拠点と防衛拠点の有利色、5編成の戦力配分になるかと思います。前哨戦1で自分は防衛拠点の有利色(緑)で固めた編成1つ、中継拠点の有利色(赤)で固めた編成1つ、ほかは残りの隊員で良さげな組み合わせを用意して5編成を組み立てましたが、比較的優勢な状態が長く自同盟の防衛拠点を確保されることがなかったので、防衛拠点の有利職で固めた編成はほぼ使用しないという状態となりました。相手同盟との交戦や拠点配置によるポイントを考えるとあまり良くない運用状態だったものと思います。

相手同盟との交戦によりポイントが入るということを考えると、自身の編成はできるだけ相手同盟の中継拠点と隣接する自同盟の中継地点に配置することが望ましいです。そのため、用意する5編成はできるだけ中継拠点の有利色を優先したものが良いと個人的には判断しています。

また戦力配分ですが、分散させるよりは防衛として強力な編成を1つ用意するほうが効果的と思います。防衛拠点を確保しようと思えば、その隣接する中継地点は必ず確保しなければなりませんが、倒しにくい編成が1つあれば相手もむやみに攻撃はできないうえに、相手を倒した場合の争奪ポイントも大きくもらえます。

相手同盟の中継拠点と隣接する自同盟の中継拠点に積極的に編成配置をする

上の話と重複しますが、中継拠点の有利色を考慮した編成を5編成用意したら、積極的に相手同盟の中継拠点に隣接する自同盟の中継拠点に配置していきましょう。

相手同盟からの攻撃でたとえ敗北したとしても、争奪ポイントは加算されます。NPCが配置されていた場合、自同盟の合計には争奪ポイントが入るかもしれないですが、個人の争奪ポイントには加算されないでしょう。任務や同盟内貢献度ランキングと言った仕組みもあるので、できるだけ配置をおこない、争奪ポイントを獲得しておくと良いと思います。

荒野のコトブキ飛行隊荒野千一夜 (JUMP j BOOKS)

序盤・中盤にどう動くか

終盤は防衛拠点を中心とした激しい攻防が予想されますが、それまでの時間はどのように振る舞うべきでしょうか。自分は前哨戦1ではわからないことだらけだったので、とにかく攻めてみようということでAPを消費していたものです。

可能であれば、相手同盟の複数の中継拠点をいつでも落とせる状態に持っていくのが良いと思うのですが、防衛拠点から離れた中継地点では効果がありません。そのため、序盤から中盤にかけては、相手の防衛拠点の2つ手前辺りまで自同盟の領域を広げておくことが望ましいと自分は考えます。

合わせて守りについても考える必要があります。イベント開始時、青の同盟は赤の同盟の防衛拠点に攻めやすく、赤の同盟は黄の同盟の防衛拠点に攻めやすく、黄の同盟は青の同盟の防衛拠点に攻めやすいといった、3すくみのような拠点配置になっています。相手の動向次第となりますが、自同盟の防衛拠点に近い相手同盟の中継拠点を叩いておき、終盤までに攻撃に徹することができる用に余裕を作っておくことも効果的かもしれません。

勝てる相手にだけ挑む

仮に自分のすべての攻撃で勝利している場合、争奪ポイントは2100ポイントにもなり、1中継拠点以上のポイントとなります。1戦負けると手に入るポイントが少ないだけでなく、相手に大きなポイントを与えてしまいます。大きく点数が動くのは終盤になりますが、それまでに負けがかさむと、防衛拠点が全同盟で確保できないような拮抗した勝負では負けてしまう可能性が高くなります。

そのため、AP溢れを逃れるための消費であっても、できるだけ勝てる相手を選んで戦いを挑みましょう。

相手同盟の中継拠点を攻めるときは自同盟中継拠点が２つ以上隣接しているところから攻める

相手同盟の中継拠点を叩いても、隣接するすべての中継拠点をとられ回復されてはAPを無駄に消費させられることになります。「相手中継拠点をいつでも落とせる状態でキープ」の項目でも話しましたが、右図の例では中継C5を攻撃しても中継C2をとられた場合、中継C5は回復してしまいます。

この中継拠点の回復をさせないようにするためには、自同盟の中継拠点が2つ以上隣接している場所を狙うべきです。

下の図を自同盟が青として見てみます。中継A3, 中継A5に攻撃を仕掛けていますが、中継A4を先に相手同盟(赤)にとられてしまうと、中継A3は回復してしまいます。そのため、先に中継A5を確保したあと、中継B4まで確保した状態で、中継A3を攻めるのが有効であると思います(そもそも戦力が分散している時点であまりよろしくない攻め方をしている)

どうしても攻撃先の相手同盟のすべての中継拠点が、自同盟の中継拠点1つしか隣接していないという場合は、短期間で確保しきってしまい、相手同盟に回復のスキを与えないという戦い方をするのが良いでしょう

逆に言えば、相手側が隣接する相手同盟拠点が1つしかない中継拠点を攻めているのであれば、積極的に中継拠点の回復を狙って相手同盟の攻撃元となっている中継拠点を叩くのが効果的と思います。

終盤までは1位にならず2つの相手同盟から狙い撃ちにされないようにする

3同盟による戦いではあるが、序盤で1同盟が大きくリードする状態が生まれると、他の2同盟はリードしている相手をまずはどうにかしようと動くのが定石です。2同盟を1度に相手にしようとすれば、戦力が分散し、APの多くを消費させられることに繋がります。

終盤まではできるだけ拮抗した状態を保ちながら、終盤に向けての準備を進めるのが良いでしょう。

よくわかっていない点

実際にプレイしてみたが解消しない点もあるので、箇条書きで列挙して今後のイベントで疑問を解消させるようにしていきたい。これらの疑問が解消された場合、これまでに話した内容から変更となる可能性があるので注意。知っている人がいれば教えて下さいm(_ _)m

イベント終了タイミングで準備中の拠点は争奪ポイントに考慮されるのか
中継拠点への配備、防衛拠点への配備をするたびに争奪ポイントが加算(累積)されるのか
2プレイヤーが同時に同じ相手に攻撃を仕掛けたとき、その行動によって発生する争奪ポイントの移動は重複するのか、APは消費されるのか

終わりに

書き出したら意外と長くなってしまい、内容もとっちらかったものになってしまった。もしここまで読み進めた方がいらっしゃったら、ここまで読んでいただき本当にありがとうございますという感謝の気持でいっぱいになる。ここから先は前哨戦1をやってみた個人的感想についてつらつらと書きます。

総じて楽しかった

イベント開始当初は何をすればいいのかわからない、とりあえずは同盟のリーダーに意見を求めつつ徐々にやっていくといった感じではありましたが、時間が進むにつれて戦況が変わっていくのは、次の展開が気になる漫画をおうようで楽しかったです。

比較的イベントに対して積極的に参加した同盟ということもあり、今まで以上に掲示板でのやり取りを頻繁に行い、考えて意見を出し合うというのも、同盟の皆さんと近くにいるようで仲間意識がとてもできたなぁと感じています。確保できました！という報告に対して、ナイス！ありがとう！などのやりとりはこのイベントが有ってこそうまれたやり取りだなと実感しています。

結果的に同盟のランキングでは1桁に入るなど、想像以上の結果をえることができ、全体的に満足できたイベントだったと自分は感じています。

時間的な制約をどう捉えるか

満足したと感じることができたのは、時間をあてることができたためとも考えられます。もしもイベントの日に他の予定があった場合は、今回ほど達成感を得ることができなかったかもしれません。また、リーダーの立場だった方からすれば、責任感のようなものを強く抱いて、時間をとらざるを得ないという状況だったかもしれません。

今までオートプレイのみで、ゲームアプリを長時間見たり起動しっぱなしということをしなかった方からすれば、時間的拘束というのがネガティブに捉えられないかは心配です。

こんな機能があったらいいな

争奪戦イベントをやっている中で、こうできればいいなと感じた事があったので列挙しておきます。

争奪戦用の専用掲示板
- コミュニケーションが活発になったことで他のコメントもながれてしまったため
拠点確保した、あるいはされたの通知
- 編成の配置という同盟メンバーの重要な行動が必要になるイベントとなるため通知があると便利
拠点マップの拡大表示
- 全体を俯瞰してみたい、スクショがとりたいと感じたので

ここまで描いた段階で次の争奪戦は中止という知らせが来ました。まぁ考えること自体楽しめたので、イベントを用意してくださった運営の皆さんには感謝しかありません。争奪戦第2弾、楽しみにしてます！

ガーラ湯沢スキー場休業のため岩原スキー場に振替えで滑ってきた

2020.02.22 友人たちと日帰りでガーラ湯沢スキー場でスノボーをしに行ったのだが、当日の朝から現場は強風が発生しており、ガーラ湯沢スキー場が休業となった

しかも休業連絡を知ったのが現地に向かう新幹線の中だというのだから友人たちと大慌て

案内をよく見てみると振替スキー場というのがあるらしく、ガーラ湯沢からシャトルバスが出るとのこと

新幹線の中で振替についていろいろ調べた中では過去の記録などから以下の情報を断片的に確認

ガーラ湯沢のリフト券が他のスキー場で引き換えられる
レンタル自体はガーラ湯沢で実施

ガーラ湯沢駅について改札を出たところのすぐ横にリフト券売り場があり、そこで詳細について聞くことができた

ガーラ湯沢でリフト券を購入し、このリフト券を振替先のスキー場のリフト券に交換してもらえる
レンタルと着替えをガーラ湯沢で行い、荷物をガーラ湯沢のコインロッカーに保管
ウェア、ボードなど滑れる状態でシャトルバスに乗って振替先のスキー場に向かう

スキー場の選択は当日の開場状態にも依存するが、この日はガーラ湯沢スキー場以外のスキー場は営業しており自由に選べる状態だった。そこで自分たちは過去に行った経験もある岩原スキー場へ行くことに決め、岩原スキー場行きのシャトルバスに乗り込んだ(過去に骨折をしたたんばらスキー場としばらく勘違いしてた)

ガーラ湯沢スキー場は最初にゴンドラに乗ってゲレンデに行くこともあり、休業の条件として風の影響を受けやすい制限がかかっていたものと思われる。そのため他のスキー場は通常通り営業しているという状態がうまれたのかもしれない。

岩原スキー場に到着しリフト券を交換、いざゲレンデへ

早朝は風も吹いていたらしいのだが、ゲレンデについて見ると雲が広がっているものの徐々に晴れてきて気温も上がり、リフトの上でも暑さを感じるほどの状態だった

雪が少ないことを心配していたが、軽く滑ってみると比較的滑りやすく転倒しても痛みを感じない程度にはふかふかとしている状態で、雪のコンディションとしてはとても良い状態

天候や外出自粛の気運が出始めていた時期ということもあってか、人の数も少なく滑っている間も人と人の間には大きくスペースができるほど悠々とすべることができ、山の上に行くほどそれが顕著に見受けられた

骨折していたこともありしばらく運動から離れていたので、久々のスノボーでどうなることかと不安になっていたが、滑ってみるとわりと体が覚えてくれてた

滑り始めてみるとやっぱり楽しい。軽快に滑り降りていく疾走感、周りの景色もよく見え雄大な風景に気分も良くなる

たまに制御できずに転倒はするものの、雪のクッションが守ってくれるので怖くない。練習にはもってこいの状況なので、エッジを立ててきれいに曲がるという練習をしばらくしてたが、右から左に流れるターンの部分でどうもバランスを崩しやすい感覚がある。この課題を確認したところでお昼休憩

お昼に頂いたのはステーキ丼！

約1500円とメニューの中では少し値は張るが、動いたあとに肉を食いたい衝動に任せて注文し、これが大正解

お肉がめちゃくちゃ柔らかくそれでいて肉と香辛料の味がガツンとくる一品。タレのかかったご飯もおいしく量は大盛りぐらいあったものの問題なく完食

ドクターペッパーは見つけたら買ってしまう呪いのかかった友人とノリで購入したが、パッケージが何故か異なるというハプニングが発生。内容は特に問題なかったものの、都会に出てしまったイケイケなパッケージと田舎に残り続けた馴染みあるパッケージとして見た目の違いを楽しんだりもした

お腹も満たしたところで午後の滑りに

リフトに乗っている最中に経験豊富な友人にきれいに滑るにはどうするかについて訪ねてみると

「スノボーを習っていた人から、エッジを立てたときに返ってくる感覚があるという話を聞いた」

という他の知り合いから教授されたアドバイスを受けた

ボードのエッジを立てたとき、ボードがもとに戻ろうとする力が働きそれに従うときれいに戻れる。転倒する人はもとに戻ろうとする力とのバランスが取れず転倒してしまうのではないか、とのこと

何を言われているのかさっぱりだったものの、もとに戻ろうとする力というのを意識して滑ってみると、たしかに立てたエッジが戻ろうとする感覚が足から伝わってくるのを感じた

この力に従うようにボードを戻すと体制が自然ともとに戻る。重心がずれるなど起こるとこの力に従うことができずもとに戻せない

今まで自分は、自全身の状態を注意深く意識することでバランスを取っていたが、ボードの力のかかり方に従うようにと意識することで、重心が後ろに行き過ぎて倒れるといったことが少なくなったように思う。この感覚を知ることができたのが今回の大きな成果だ

しばらく滑っていると黒い雲が出始めてきたので混雑回避も含めて早めにガーラ湯沢スキー場に戻ることに

ガーラ湯沢スキー場は銭湯もあり、ロッカーで着替えなど必要なものだけをもって脱衣所に向かうことができる。ただこの銭湯、ロッカーと脱衣所の区別がわかりにくくなっており、ロッカーのところですべての服を脱ぐのかと最初は勘違いしていた。張り紙がありよく見ると脱衣所は更に進んだところと書いてあり、最低限の着替えとタオルなど以外はロッカーに置いておく決まりのようだ。このあたりはちょっと分かりづらい

銭湯の洗い場は10程度あり、自分たちが入ったタイミングは特に混むといったこともなかったが、30分違えば混雑しそうな人の混み具合だった。比較的少ない入場者だったことを思えば、ピーク時は地獄絵図となりそうだ

荷物をまとめて新幹線で帰路につく。すべての道具を持っているとレンタルでお金はかからないが移動時の負担がやはり大きい。次は荷物を宅配などに委ねることも検討しなければ。

久々のスノボーはめっさ楽しかったなぁ。ある程度滑れる感覚も取り戻したしもっと滑りたいと思うものの、新型コロナの感染拡大防止などを考えると今シーズンは難しそう。来シーズンは今シーズンで滑れなかった分も合わせてたくさん滑るぞい！∠( ﾟдﾟ)／

Go言語勉強します

ボイスロイドによるSplatoon2の実況、通称ボイロトゥーンの動画を作成してて、セリフを打ち込んだあとの画像選び(PSDからボーズなどを決める作業)のときに

「セリフから自動的に適当なPSD画像にしてくれるようにできないかな」

そんな戯言をTweetすると・・・

(　ﾟдﾟ) ・・・

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ) ・・・

(つд⊂)ｺﾞｼｺﾞｼｺﾞｼ

(；ﾟдﾟ) ・・・・・・・・・・

開発者ご本人様からリプライ！？

これはやるしかないですね。開発言語はGo言語で今まで触ったことないですが、いい機会なので勉強してやりたいことができるようにしたいと思います。

PullRequestあげて取り込んでもらえたりしたら夢のようではあるけれど、やろうとしてることけっこう複雑になりそうやから分離して用意することも検討しとかんとな(；・∀・)

いやそれにしても驚いた。言うてみるもんやな。。。

声月六参加レポートとか感想とか

参加はしたのですが、午前中に他の予定とブッキングしてしまい、14:20ごろから参加という終了間近からの記録なので情報少ないかもです(；・∀・)

会場到着(14:20ごろ)

午前中の予定が終了してから急いで声月会場の大田区産業プラザPiOに。 15時終了のイベントなので、すでに撤退される方とすれ違いながら、入場券代わりのパンフレットを購入して会場入り

入り口には弦巻マキのコスプレ(?)をした人が立っており、思わず写真をお願いしてしまった。カツラとかじゃなくて顔も含めた被り物をかぶってるのねって感じで最初に視線を奪われたｗ

入場して左手に進んでいくと結月ゆかり、弦巻マキ、紲星あかりの等身大のパネルや、バイクにイラストを入れたものなどが展示されていた。このあたりだけを見ると、この3人に関する物が多いのかなという印象。

普段同人誌は購入したりしないのだが、今回で声月のイベントは最後ということなので、空気感でも知っておきたいなと思いタイトなスケジュールではあるものの強行した。そのため、目当ての場所というのがあったわけではないので、どんなものが並んでいるのだろうとしばらくブースをぶらぶら。

そしたら、紲星あかりの猫耳のコスプレをした可愛い人を見かけたので写真を取らせてもらった。撮りやすい場所に移動したときに気づいたんやけど、けっこうコスプレしてる人いるのね。

いろいろ見て回ってたんやけど、終了時間が近かったためか、撤収準備の雰囲気を感じたので、自分も帰路についた。午前中の予定がフットサルで疲労が足にきておりこのときは早く休みたいと考えていたと思う。

声月アフター

電車で数駅離れたタイミングで、知り合いがまだ声月の会場にいるというのをTwitterで知り、しかもその場にdiscordでしかまだ話したことのない知り合いもいるというではないか。まだその場に残っているかを聞いてみるとその知り合いから

「終了後に声月アフターという名のじゃんけん大会がある」

なん・・・だと!?( Д ) ﾟﾟ

まだイベントは終わってなかった。急いで会場に戻りなんとか声月アフターのイベントが始まる前に友人と合流もできた。実際に会うのは初という友人にも挨拶できてよかった(フットサルのあとだったので実は汗臭かったのではないかとこれ書いてるときになって心配になってきた)

前回の声月を知る友人によると、声月が終わったあと、参加されたサークルや企業が色紙などの景品を用意しており、これをじゃんけんで勝った人が獲得できるというじゃんけん大会を声月アフターというらしい。

運が良ければなにかもらえるかもしれないと、友人に会ったことで再度高まったテンションで意気揚々と参加！声月アフターの参加者はどんなものかと見てみると、会場いっぱいに人がいる(ざっくり勘定で200～300ほど)。この中でじゃんけんに勝ち残るというのはなかなか至難の業やな。。。

そして始まったじゃんけん大会。対象の景品が発表され、欲しい人は声月準備会代表の銀鮭さんに勝ち続け、人数が少なくなったらその人達の中でじゃんけんというのを景品の数だけ繰り返す。最初はみんな座った状態から、銀鮭さんとの最初のじゃんけんで勝った人は立ち上がり、その後のじゃんけんで負ければ座る。勝ち続けた人たちだけが立って残っているという仕組み

このじゃんけん大会の中でも大きく喜ぶ人、銀鮭さんのじゃんけんマスター権限に対抗しようという参加者の一致団結感、松阪牛1万円相当が封入された色紙に沸き立つ会場などなど、たくさんの盛り上がりがあり、とても楽しかったです。

しかしながら、じゃんけんのたびに立って座ってを繰り返すのが自分にはかなりこたえた。なにせ午前中にフットサルをしており、足はすでに疲労困憊。かといって景品も欲しいのでじゃんけんに挑まなくてはいけない。かなり数もあり、全ての景品が出し尽くしたあとは、すぐに立ち上がることができないほどに足の感覚がおかしくなっていた(;´д｀)

それでも、このスクワットのかいあってか、2つの色紙(ひとつはCDつき)をゲットすることができました!!ヽ(=´▽`=)ﾉ

色付きのとてもきれいなずんこさんは趣味工房にんじんわいんのARAさん
煽られてるのに見ると笑ってしまうきりたんは月下美刃サークルのエロムラサキさん

これを機に、このおふた方のアカウントをフォローし、イベントなどで即売会をやっていたら、買い漁っていきたい所存です(｀･ω･´)ゞ

欲を言えば、琴葉姉妹関連のものが手に入ればなとも思ったり(´-`)

おわりに

初めてでわりとノープラン、しかも終了近くからの参加となりましたが、ボイロ勢の賑わいを見ることができてとても楽しかったです。とくに声月アフターを教えてくれた友人には感謝してもしきれません(´；ω；｀)

次もこういったイベントがあれば今度は1日開けておき最初から最後まで全力で楽しみたいですね。運営の皆さん、本当にお疲れさまでした。

趣味工房にじいろわいんさん関連リンク
- https://carrotwine.stores.jp/
- https://carrotwine.booth.pm/

立飛のコトブキ航空祭(その2)

こちらの記事は前回投稿した記事の続きの記事となり、2020.02.01に行われた立飛のコトブキ航空祭の第三部以降の内容となります。前回の記事をまだ見ていないという方は、よろしければ立飛のコトブキ航空祭(その1)を御覧ください。

また、odajun の記憶を頼りに記載しておりますので、実際の内容と異なる部分があるかもしれませんのでお気をつけください。

第三部「コトブキおじさん大集合！細かすぎて伝わらないトークショー」

開演ギリギリに入ってみると、期待通り前の方の聞きやすいポジションに、詰められていない席があり空いている。時間を目一杯有効に使えるというのは自分としては嬉しい発見。

このトークショーは再放送の荒野のコトブキ飛行隊の副音声で行われていたものの出張版ということでしたが、軍事評論家の岡部いさくさんは初めて見る名前でした。どんな方なのかと注目していると、とてつもない個性を炸裂させ、短時間で完成させる絵をもって詳細な解説をしつつ、「隼は最初あまり好きではなかった」発言からの「とてもかわいい！」までの下りは面白かった。注目するところそこなの!?と驚かされるばかりで、トークの内容というよりは岡部いさくさんを覚えて帰ったという印象が強いです(;=ω=)

二宮さんが、モデリングデータから3Dプリンタで1/700スケールの羽衣丸を制作される過程について話してくれました。

3Dプリンタによる制作のあれこれも興味をそそる内容でしたが、実際にどのあたりに通路があって、このシーンではここに誰がいてという俯瞰した視点で羽衣丸の内装を見れたのが興味深かった。

また、二宮さんは日本一(世界一?)戦闘機の横からの図を描いていると豪語され、世界の戦闘機のナンバリング(戦闘機への型番記載)の違いについて詳しく説明してくれた。ナンバリングは各国によって異なるのはまだわかるとして、描き方の統一性について語ることができるのは、多くの戦闘機を描いてきた二宮さんならではの分析で面白かった

内海さんのお気に入りのシーン紹介では、飛行機乗りの自分から見たときにやらない(あるいはやりたくない)シーンが一部取り上げられてる印象でしたね。逆Gってどれぐらいつらいもんなんやろ。

あと印象に残っているトークとしては、震電の離陸シーンを見てみたい、震電の空中で停止したような動きしたら冷却できないよね、といった震電を中心としたコトブキ飛行隊の中でも夢を詰め込んだあたりの話ですかね。

岡部さんもおっしゃられていた、リアルな部分への細かいこだわりを持ちながら、実際にはなかった(あるいはできなかった)部分をいい感じに混ぜているのがこの作品の良いところというのは、たしかにそうだなぁと共感してました。震電のエンジン音とか記録あったりするんか？

ただ、話がコアすぎて置いてけぼりとなってしまった時間帯もあって、もっと勉強しとけばよかったと思う反面、こんなコアな話をする場所なんだなと皆さんの知識の広さ、深さに感服してました。自分も岡部さんのように笑顔で隼の良さを語ったりしたいものです。

展示エリア「コトブキ資料館」

第三部終演から第四部開演までの間に、アリーナ立川立飛内に用意されている、コトブキ資料館に足を運びました。ここにはアニメの原画、コトブキの1年の歩み、作品に関するその他資料、ゲーム体験コーナーなど、広いスペースに数多くのコーナーが並んでました。

多くのコーナーがある中で自分の目を引いたのは、ズラッと並べられた等身大パネルの数々。魅力的なキャラが多いコトブキ飛行隊ですが、こうやって並べると壮観ですね。ロイグの身長が思ってた以上に大きくて、後ろのキャラクターをちゃんと写すにはなかなか角度が必要でした。

展示のひとつの目玉、立飛ホールディングスの敷地内で発掘された航空機用エンジン”ハ115″

隼二型に積まれていたと言われるエンジンで、実物をみるのは初めてでした。航空機のパーツひとつでこの大きさなのかと非常に驚きました。

二宮さんがトークショウのときにおっしゃっていたのは、プラモデルを作る人にとっては、細部が実際にどうなっていたかを実際に見る(知る)ことができ、今まで想像で補っていた部分が事実をもとに再現できる。歴史的にも非常に価値のあるものだ、ということをおっしゃられていましたね。

原画以外は写真撮影OKであり、帰ってからも確認ができるというなんとも親切なルール。これに甘えてこれでもかと写真を撮ってきました。

第四部「エースコンバット7×荒野のコトブキ飛行隊スペシャルトークショー！」

エースコンバットやったことないんやけど大丈夫かなと思いながら参加したトークショー。終わってみたらエースコンバットめっさやってみたい！という気持ちになってましたｗ

エースコンバット陣営の河野一聡さん、下元学さんと、コトブキの伊藤さんはけっこう親交があるようで、河野さんは伊藤さんの以前の上司、そして下元さんとは会社の同期とのこと。話をしている姿を見ると本当に仲がいいなこの人たちと感じるばかり。

エースコンバットからはサウンドチームからのアドバイスや、エースコンバットの塗装、格納庫のBGMなど数々協力を頂いているという中で、伊藤さんがお返しします！といって出てきたコラボがコトブキのエンブレムをエースコンバットの機体に載せるというもの。サンプル画像も出たけどなんかかわいいなというコメントも。これエースコンバットの世界観壊さない?(;・∀・)

そして内海さんのエースコンバット7VR公開プレイコーナー。現役パイロットが戦闘機のゲームをやってみるという内容で、実際の空に近い感覚を目指しているエースコンバットの河野さんは「監修を受けてるみたいで緊張する」といったコメントも。

機材トラブルでジョイスティックのコントローラーは使えず、通常のコントローラーになるという事態になるも、始まってみれば順調に敵機を落としていく内海さん。内海さん自身は「期待しないでください」と言ってはいたものの、素人目に見てもうまいのがよく分かる。首をしきりに動かして周囲の警戒・索敵をする姿は戦闘機に乗るパイロットそのまま。無事ミッションをクリアしたあと内海さんの口からは、「戦闘機を乗っている感覚に非常に近い」といった開発側にとっても嬉しい言葉が出た。このコーナーを見ると本当にエースコンバットが欲しくなる、というか後日買いました(;´∀｀)

エースコンバットの開発チームの支えもあると以前から知ってはいたものの、伊藤さんがつないだことで生まれたコトブキの細かなこだわりを思うと、伊藤さんだからこそ実現した作品なのかなと感じますね。

「荒野のコトブキ歌謡祭2020」

この日最後のイベント、荒野のコトブキ飛行隊の曲で彩るコトブキ歌謡祭

ザラ(山村響さん)とレオナ(瀬戸麻沙美さん)による開幕前の注意事項アナウンス(影ナレ)では、ザラがセリフを噛んでしまうというアクシデント、でも可愛い。

キリエ役の鈴代さんがあのパンケーキの歌を歌謡祭用にしたものを歌いながら登場し開演。ZAQさんによる「ソラフネ」が披露され、コトブキのメンバーが全員登場。瀬戸さんによる一気入魂の掛け声のあとにキャラソンが続いた。

チカ(富田美憂さん)によるポッピンヒーローは1番槍にふさわしく、会場を一気に盛り上げるパフォーマンス。「おじさんたち！」とあおり会場に更に熱を加えてた姿がとても印象的だった。合いの手の入れやすい曲ということもあり、会場の一体感も得られ最高でした( ﾟ∀ﾟ)o彡°

続いてエンマ(幸村恵理さん)の Poison Dahlia は、とにかくかっこいい。マイクスタンドを使ったポージングもキマってて惚れそうでした。ただ、冷静になって考えてみるとエンマに「ダニども！」と言われて盛り上がる会場というシーンに笑いがこみ上げてくる(;´∀｀)

そして、どんなふうにパフォーマンスするんだろうと不安と期待を抱いていたケイト(仲谷明香さん)の「沈黙的アナリスト」

合いの手があるわけでもなく、会場のみんなも曲に合わせてペンライトを振って盛り上げ方を模索している感じ。曲中、ケイトがつぶやく部分で「盛り上げるのは難しい」といったセリフに変えて話していたのが印象深い。難しいだろうなということを聞き手もわかっている、それでもなんとか一体となって応援したいといった気持ちもあったり、それでもステージでこの曲を聞けることがただただ嬉しい。

一度トークを挟んで始まったのはZAQさんによるゲームで使用されている曲の披露。しかも、ハルカゼ飛行隊、怪盗団アカツキ、ゲキテツ一家の楽曲をセルフカバー！これにはしびれました。実際は各キャラで歌われている楽曲をZAQさん1人でキャラの歌い分けをやってのけてる。作詞作曲をした本人とはいえ、このパフォーマンスには感謝感謝(=人=) 今後の楽曲にも期待が高まるばかり。

このあと予想外だったのが、エリート工業社歌を会場全員で歌うというもの。なんの知らせもなく突然曲が流れて会場も戸惑いの色を見せたものの、そこは優秀な隊員たち、歌いだし完璧でしたね(ﾟ∀ﾟ) ただ、2番以降はけっこうみんなあやふやみたいで、曲が進むにつれて音量が下がっていた気がするｗまぁ自分も1番までしかはっきりとは覚えていないんですけどね(;ﾟ∀ﾟ)

ザラ(山本響さん)のセクシーな楽曲「雪ぐ愛、同じ夜」で会場は盛り上がるというよりは、ザラに釘付けになるというような雰囲気に。そしてレオナ(瀬戸麻沙美さん)とハイタッチをしながら交代し(このシーンが形容しがたいほどに良い)、「 Let it out 」を歌い上げる。レオナのうちに秘めた感情を描いた歌詞は、何度聞いても心に響き、レオナというキャラクターをより一層魅力的にしていると思う。ZAQさんすごい。。。

キャラクターソングのトリを飾ったのはキリエ(鈴代紗弓さん)の「 LIMITLESS∞DREAM 」

ザラ、レオナと、オトナな雰囲気に少し落ち着いた会場を今一度ヒートアップさせるような、必死で声を張り上げていたキリエはステージ上でとても輝いて見えた。

すべてのキャラソンに「飛ぶ」というワードがありながら、どういった気持ちを持って飛ぶのか、というメッセージが込められており、6曲合わせて一つの楽曲なのかもしれないと自分は考えてたりしてます。

ZAQさん含めた7人全員が再度ステージ上に登場し、「翼を持つ者たち」を歌ったあとメンバーそれぞれ隊員へのメッセージで、幸村さん、鈴代さんが涙ながらにコメントしてたのは目頭が熱くなりました。1年前からは想像もつかないくらいのファンの広がりを見せ、大きなイベントまで開催できるという状況が、出演者側からすると本当に夢のようなことなんだろうなと感じた。

「太陽が呼んだ虹」を最後に熱唱し歌謡祭は幕を閉じ、同時に1日に渡るコトブキのイベントが終演となりました。

おわりに

この日は非常に濃い1日で、改めてこうやって書き出しては見ましたが、おそらく拾いきれていないことがあり、もっとあんなことやこんなこともあったとあとになって思い出したりするんだろうなと思います。サイトの構築し始めという状態だったので、まずサイトの補強をしていたらイベントから記事の投稿までに1週間ほど経過していて、実際とは異なる形で記憶している内容もあるのかなと。

ただそれでも、とても楽しい1日であったということ、荒野のコトブキ飛行隊というコンテンツに出会えてよかったと感じたこの日の気持ちはしっかりと覚えておきたい。

以下は紹介しきれなかった画像たち

立飛のコトブキ航空祭(その1)

まえがき

荒野のコトブキ飛行隊がアニメ、アプリゲームで配信されて約1年、初めての大型イベントが2020.02.01 に開催されました。その名も立飛のコトブキ航空祭

この記事はその時の思い出を実施されたイベントをなぞりながらつづったり写真の置き場所として用意しています。

はぁ。。。楽しかった。。。(´-ω-)=3

開場前～第一部トークイベント開始前

作り込まれた世界観やシナリオ、戦闘機にもともと興味があったということもあり、荒野のコトブキ飛行隊に初期からのめり込んでた自分は、このイベントが告知されたときから楽しみでたまらなかった。

多摩モノレールで景色を眺めながらイベント会場のアリーナ立川立飛/ドーム立川立飛の最寄り駅、立飛駅に到着したところ、改札をくぐろうかというところで予想外のお出迎えに驚かされる

まさか自分の推しキャラであるリリコさんが最初に出迎えてくれるとは！！( ﾟдﾟ)

この日の最初の写真をリリコさんで飾れるとは、幸先が良いなと思いつつ、あまり眺めていると他の隊員さんたちの邪魔にもなりそうだったので会場へ向かう。改札内のけっこう狭い空間だったのでゆっくり見れなかったのがちょっと残念(´・ω・`)

あとで知ったんですがアンナとマリアのパネルも駅にあったんだとか。完全に見逃した。。。

10時からイベントスタートというのに対して自分は9時半ごろと早めに来たつもりだったのですが、そこにはすでに人の列。最初のトークイベントが11時頃ということもあってか、その列の大半は物販列。

自分も最初に買い物済ませるかとならんでは見たものの、進まない。10時を超えて列が会場内(ドーム内)に移っても、進まない。。。

アリーナ内には新しいキービジュアルや、キャラクターの等身大パネル、実物のレシプロ機“R-HM型軽飛行機”の展示があり、並びながら遠目に眺めることはできたが、どうせなら近くに行ってじっくり見たい、写真撮りたい(´ε｀；)ｳｰﾝ

何故かミスタードーナツが出張販売してる。加えて写真NG
ドーム内で写真NGやったんドーナツのところだけやったんでは？(=ω=；)

並んでいる人数に対して物販の回転があまり良くなく、結局トークイベントの時間が近づいてきたので、このタイミングでの物販を諦めて、まだ人が少ないうちに展示などの写真を撮ってしまおうと切り替え。

新しいキービジュアル、めっさかっこええわ～ヽ(=´▽`=)ﾉ
広大な荒野と青く広がった空、そして並んだ戦闘機にキリエと他の隊の隊長たちが並んでて、コトブキの主要素をきれいに配置した素敵な絵でしたね。ドードー船長もちゃんいるw
戦闘機の翼に足をかける、座るというのやってみたいんですよね。なんとなくかっこいいなという印象をずっと持ってる

実際のレシプロ機も実物見ると迫力あるんよな。比較的小さめのものやと思うから、実際コトブキのみんなはけっこう大きなサイズの乗り物乗りこなしてるんやなぁと改めて実感

R-HM型軽飛行機に乗って飛んでみたいなぁとか思ってたけど第三部のトークショウで「操縦難しいよあれ」って話してて、まじかっ!?ってなりましたな。見た目練習機みたいなのに(;・ω・)

プライマリーグライダーというすごく細身の乗り物の展示もあり、これには実際に乗って操縦についてレクチャーを受けることができた(飛んではいないよ)

手元のレバーと足元のペダルを操作することで実際に尾翼や翼がどう動くのかを体感できたのは楽しかった。レバーを傾けたときに船体も傾いたことに驚いてたんやけど、スタッフさんが翼のところ支えながら傾けてたｗ実際はこう動くんですよって教えてくれてたんやな

第一部「コトブキ通信出張版 in 立飛のコトブキ航空祭」

生コトブキ通信！配信されてたものはデフォルメされたキャラが喋ってる感じで、それはそれで可愛くていいんですが、実際にどんな身振り手振りしてるのか見れるのもいいですよね

入場特典は「4コマでわかる！あらすじまとめクリアファイル」コトブキ通信でやってた各回を4コマイラストで振り返るものを1つにまとめたもの。回を追うごとに絵がうまくなっていて成長が伺えるのがまた面白い。個人的にはリリコさんとジョニーが描かれたひとコマがお気に入りです。

★「立飛のコトブキ航空祭」入場者特典を公開①★
「立飛のコトブキ航空祭」にて実施される各ステージの入場者特典を公開！
第一部「コトブキ通信出張版 in 立飛のコトブキ航空祭」では「4コマでわかる！あらすじまとめクリアファイル」を配布！
詳細はこちら→https://t.co/cPmTjaxF91 #コトブキ pic.twitter.com/XPs3Wwm7hK
— TVアニメ『荒野のコトブキ飛行隊』公式 (@kotobuki_PR) December 27, 2019

開幕のトークはキリエ役の鈴代さんが今朝寝坊したという予想外の内容 ( ﾟдﾟ)ｴｯ!

みなさんリハーサルなどで前のりしてたこともあってか、鈴代さんの目覚ましがずっと鳴っているのを聞いてるっていうのも面白かったですね。「細かくスケジュール管理してるのかな」みたいに思ってたらしい(;・ω・)

コトブキ通信でおなじみ(?)のワンシーンで大喜利するコーナー、難易度高そうですねあれ。。。笑いというよりも、時間内になんとかひねり出してた皆さんすごいなと素直に感心してました。

そしてこの場で発表となったのは、映画化のお知らせ！

アニメのシナリオの再編とはなるものの、オリジナルエピソードも含んでる。設定が謎の部分が多いコトブキのどの部分が話されるのか、期待が高まる。

こだわりの音響を映画で楽しめる、しかもMX4Dもある！これは体感せねば!
まだまだ先にも楽しみがあって本当に嬉しいヽ(=´▽`=)ﾉ

コトブキの皆さんからの、映画に含めて欲しいエピソードもなかなか尖っててよかった。レオナがスリッパ履いてるとか実現してまうのでは?w

コトブキ飛行隊全員が集まったトークイベントもあっという間に時間となり、最後はパンケーキの一言を誰が言うかで男気(?)ジャンケンをする皆さん。負けてしまった人は本当に悔しそうだったなー(棒)

ここで鈴代さんが勝ってしまうあたりは、さすがもってるなぁって思いましたねｗ

第二部「祝・1周年！船長たちへの大感謝祭 in 立飛のコトブキ航空祭」

第一部が終わってすぐに第二部の列に並んで、会場に再び入ったときに気づいたんですが、基本的に皆さん席は自由で、特に配置について整備しているスタッフもいなかったので、ステージ前のいいポジションにもちらほら空席が残ってるんですよね。次はわざと遅めに入場して、空いている前の方に座れるか試してみようとか考えてました。

そして第二部が始まって、各隊の隊長がステージに全員出てきたとき、個人的に目がいってしまったのはユーカ役の本渡楓さんの衣装ですね。「まんまユーカやん！」って声に出そうでした(;´∀｀) あれだけ衣装合わせるの大変だったんじゃないかな。強い意気込みを感じましたね。

本渡さんだけでなく、朝井彩加さんも髪型と衣装をフィオに合わせててめっさ可愛かったわぁ。朝井さんにいっきにハマってしまい、すぐにTwitterのアカウントをフォローしにいきました(=ω=)

ちなみにドーム立川にあったスタンプはフィオのスタンプを自分は押しました。

瀬戸麻沙美さんはなんというか、天然なのかなと思う場面がちらほらｗ

ゲーム内景品のかかったクイズで、「これは明らかにBだよね」という会場全体の空気を感じていながらAと答えた瞬間は最高でした。本人もすぐに「ちがうちがう！」と言ってましたが、いったい瀬戸さんの中ではどういった考えがあったのか謎のままです(;´∀｀)

このトークイベントでは比較的ゲームに即したものが多く、キャラクタラーランキングや、イラストコンテストの結果発表がありました。キャラクターランキングは隊長たちはロマンが好きという結論になったり、イラストコンテストではかっこいい塗装とともにとうもろこしとインコの塗装が受賞しているのがなんとも言えないおもしろさを醸し出してた。次回は自分もチャレンジしてみようかな(･ัω･ั)

どの隊に入ってみたいかという話題では、ゲキテツ一家の人気が光ってましたね。気持ちはわかるけど幹部以外の人たちが怖そうなんよなぁ(幹部が怖くないわけでもないけど)

MCの松本忍さんと佐々木義人さんが面白く全体を回してくれてて、というか佐々木さんが隊員の気持ちを上手く代弁していたような気もする。佐々木さん自身もゲームにハマっているというところがとても良く働いた感じがありますね。

このイベントでゲームに関する発表が続々と出て、今後もしばらくはコトブキ飛行隊から抜けられそうにありません(喜)