Build Insiderオピニオン：河合宜文（3）
C#における構造化ログの手法、そしてデータ可視化のためのDomoの薦め
最近、より重要性を増しているログ。グラニではログをどのような方法で扱っているのか、そして、その根底にあるグラニのポリシーとはどんなものだろう。
グラニにおけるログの扱い
ログは「障害対応の際の異常の確認」や「パフォーマンス改善」などのインフラ関係を目的とした利用から、ビジネス上の解析まで、さまざまな用途で使われます。非常に重要なものですが、Windows環境における.NET Web開発において大きく欠けているプラクティスがこのログの扱いです。
テキストファイルに、人の読めるバラバラのフォーマットのログを吐く。いまだにそんな旧態依然とした手法から脱却できず、ログの扱いといったところで、「ロガーをlog4netにするかNLogにするか」というレベルにとどまっているのではないでしょうか？ というのはあまりにも偏見ですが、しかし、Fluentdの活用を始めとした世の中の風潮からかなり遅れているのは事実だと思っています。実際、Windowsにおいてどう処理すればいいのかということに対する意見を見ることはあまりありません。
グラニではどうしているかというと、ログはテキストでは取り扱わず.NET 4.5から追加されたEventSourceクラスを用い、ETW（Event Tracing for Windows） を経由して、Semantic Logging Application Block（SLAB）のOut-of-Processサービスで処理しています。そして、SLABにより最終的にGoogle BigQueryへ転送して解析対象としています。
ログはテキストに保持しているだけでは、量が増えれば増えるほどに読みづらくなるものです。さらにこのクラウド時代では、複数台規模でアプリが実行されることも普通のことで、そうした環境になると、テキストに保存しているだけではログの管理はすぐに破綻します。もはや、ログは人間の読むものから機械が読むものへと時代は変化しているのです。従ってその形式も、人が読みやすいフォーマットで出力していた今までの非構造化ログから、機械の読み取りやすい構造化ログ（＝JSONのようなキーとバリューで整形されたもの）へと変わる必要があります。そして、人が読む際には、柔軟なクエリによって素早く整形／集計されたものを返してくれるようになればよいのです。
そのようなシステムにするためのロガーとして上述のSLABを選ぶのがよいかどうかには未知数なところもあります。しかし、いずれにせよ、ログの取り扱いの未来、今後どうしていくべきかの方向性はそこ（構造化ログ）にあります。現状、.NETにおいて構造化ログフレームワークの決定版といえるものはありません（SLABの他に.NETで構造化ログを扱うためのロガーとしてはSerilogがあります）。しかし、SLABはETWとの組み合わせやIn-Process／Out-of-Processという概念を持つなど、他のロガーに比べて一歩抜けた概念を持っていて、試してみる価値はあります。現状ではあまり動きはありませんが、GitHubのmspnp/semantic-loggingにフィールドを移し、次へのロードマップを練っている段階のようです。
SLABからの転送先となっているBigQueryはSQLライクなクエリで、小さいログでもどれだけ膨大なログであっても驚異的なスピードで答えを返してくれます。その上、非常に安価なログストレージが提供されているので、容量を考えずにログを詰め込みまくれるのもよいところです。このように競合に比べて圧倒的な性能を持っているため、たとえ現在利用しているサーバーがAzureであっても、AWSであっても（弊社はAWSです）、オンプレミスであっても、利用する価値のあるサービスといえるでしょう。
可視化ダッシュボードという課題
BigQueryでログをためられるようになったし、アドホックなクエリはWeb上のクエリ画面やLINQ to BigQuery＋LINQPadを通してExcelに流して解析できるようになったしと、ログの解析環境は以前とは比較にならないほど充実しました。のですが、しかし、定期的に解析結果を確認するためのダッシュボードや、可視化ツールについてはどうすればいいのでしょう？ そもそもBigQueryでうんぬんの前に、アプリのデータベース（MySQL）に蓄積されている生のデータや、それらを基に集計を行った結果を確認するための自社構築のダッシュボードではろくなグラフ化を行えず、データを表のまま出すだけの機能しかないまま、今まで来てしまったのです。
ビッグデータ！ データマイニング！ などとまでいわなくても、現在動いているアプリのデータベースにはビジネスを進める上で大事な情報が眠っています。売上データ、ユーザーの現在の状態、etc。重要さの度合いとデータの大小は関係ありません。いい加減このままではよくないと思いつつも、これまでは手を打てていなかったのですが、BigQueryの導入がちょうどよい機会となり、全体的に本格的に見直そうというプロジェクトが始動しました。
Domo
結論からいうと、グラニはDomoというサービスを利用することを選択しました。
Domoは純粋なクラウドサービスで、データソースからのデータの取得・結合・可視化が全てWeb上で完結しています。データの分析や可視化というと、BI（Business Intelligence）ツールが真っ先に頭に浮かびます。もちろん、それらも検討しました。しかし、どちらかというとそれらはデスクトップツールによる高度な分析が中心で、ダッシュボードによるWebでの情報共有は添え物的であるものが多く、私たちの要求をあまり満たしてはくれませんでした。まず優先したかったのは会社中の誰もがデータを確認できることと、アプリに関わる人間が思い立ったらすぐに表示用のクエリを作りダッシュボードに追加できること。それらを完璧に満たしていたのがDomoでした。
Domoの掲げるクラウド型のBI。そのコンセプトは私たちの要求にマッチしていたのですが、競合製品はもちろんあります。マイクロソフトのPower BIやBIME、Chartioなどがそうです。その中でDomoを採用した決め手はいくつかあります。特にDomoのUI／UXは非常に秀でたもので、一見地味で派手な美しさはないのですが、確実な使いやすさと、正しく情報を見せることに100％フォーカスしたデザインと機能は魅力的です。それ以上に大きな決め手となったのは、豊富なデータコネクターと、Dataflowという強力な結合機能です。この二つの機能がグラニの要求を理想的に満たしてくれました。
データの在りかは分散しています。MySQLにもあれば、BigQueryにもあります。Excelにもあるだろうし、Googleカレンダーの中にだってあれば、JSON APIで取れるものもあるかもしれません。Domoには数百を超えるデータコネクターがあり、これらを使うことで、あらゆるデータソースに対してDomoが問い合わせを発行し、データを取得してくれます。リトライやスケジューリングも完備されているため、ダッシュボードのためのワークフローに悩む必要がありません。
残念なことに、数百を超えるデータコネクターといっても、対応しているもののほとんどが海外のサービスばかりで、日本のサービスはやはり手薄ではあります。それでも、MySQLやSQL Serverなどのデータベース系やBigQueryやRedshiftなどのビッグデータ系が網羅されていることと（Power BIはBigQueryにつながらなかったりするのでその時点で落第となった）、ExcelなどのファイルデータはBoxなどのクラウドストレージ経由で同期させられること（もしくはDomo Workbenchというソフトをインストールすることでスケジュール化された自動アップロードが可能）、そしてAPIが公開されているサービスならばJSON APIやXML APIで直接問い合わせることが可能なことから、ほとんどのケースはカバーできるはずです。
Dataflow
「データをどうやって結合するか」はDomo以前でも大きな課題でした。もともとグラニではデータベースを垂直分割していて、一つのアプリでも5～6台に分けてデータが蓄積されていたため、別のデータベースにデータがあるため単一のクエリでは結合しきれないものもありました。アプリケーションを超えた横断的な分析や、データ結合の対象にBigQueryまでを含めるとなると、そもそもつながりがありません。単純なところでは、例えば表示結果のラベルに数字のidが並んでいても意味不明です。別なところにある（別のデータベースかもしれませんし、Excelの中にあるのかもしれません。あるいはアプリのソースコードに埋め込まれていることだってあるかもしれません）マスタデータと結合して数字のidを文字列ラベルに変換した結果が表示できなければ、誰もが見て理解できる直感的なダッシュボードにはなりえません。
Domoは複数の結合機能を提供していますが、グラニでは「Dataflow」という機能のみを利用しています。Dataflowはばらばらのデータソースにあるクエリ結果（データソースがRDBMS系なら生SQLを書く）をDomo内部の一時的なMySQL、もしくはAmazon Redshiftにインサートし、そのインサートされたテーブル群に対して生のSQL文を書くことによって自由自在な結合を可能にしています。原理は非常に単純ですが、ほとんどのケースでこれはうまくいき、「そう、それでいいんだよ！ こういうのが欲しかったんだよ！」と思わずうなってしまいました。
それぞれのデータソースに対しては個別のクエリしか吐けないので、一体化した超巨大なデータセットと見なして集計クエリを発行するといったことはできませんが、そのようなシーンが頻発するならば1カ所に集めるなり（MySQLとBigQueryを同期させてBigQueryだけで完結させるなど）すべきで、Domoでやる話ではないでしょう。
Dataflowではデータソースへのクエリから、結合段階まで、一貫して生SQL文を書く必要がありますが、逆にBIツールにありがちな、GUIツールでの操作により自動生成されるおかしなクエリしか使えず、思ったようなクエリを書けないよりも、エンジニアにとってはずっと直感的で好ましいものです。グラニではアプリに関わるエンジニアが自ら生SQL文を作成するというフローになっているので、全く問題がありません。なお、生SQLが不要なDataFusionというシンプルなデータ結合機能も用意されているため、Domo自体はエンジニアのいない会社であっても大丈夫という設計になっています。
最良を模索する
グラニは「using CSharp;」を掲げており、また、社内に多数のMicrosoft MVPが在籍していることもあり、マイクロソフト製品に非常に好意的です。しかし、最優先事項はビジネス面での成功であり、マイクロソフトにとらわれすぎることなく、最も良いものを選ぶことをポリシーにしています。その結果、C#を使っていても採用するツールとしては、AWSやBigQueryやDomoを選んでいます。
よいものを選ぶ。それは簡単なようで、軸がなければただの寄せ集めでブレてしまいます。C#という軸を絶対の中心としてぶらさずに最先端を突き進むこと。それがグラニの強みであると思っています。
河合 宜文 （かわい よしふみ）
株式会社グラニ取締役CTO。Microsoft MVP for Visual C#。特にLINQが非常に好き。最近はUnity開発においてもLINQをフル活用するために、Unity用のReactive Extensions「UniRx」を作っています。
・ブログ: http://neue.cc/
・Twitter：@neuecc
1. 最先端のC#環境で働く開発者が感じたVisual Studio 2015移行への期待
最先端のC#環境でゲーム開発を行っているグラニでは、Visual Studio 2015 Previewを見て何を感じたのか。LINQとReactive Programmingで有名なneuecc氏によるコラム、始動。
2. Visual Studio 2015を前のめりに使いこなす！ Analyzerの社内導入と展開
「using CSharp;」な企業であるグラニでは、Roslynが提供する「Analyzer」と呼ばれるコードの解析／生成機能をどう活用しているのか。その秘訣をチラリとご紹介。
3. 【現在、表示中】≫ C#における構造化ログの手法、そしてデータ可視化のためのDomoの薦め
最近、より重要性を増しているログ。グラニではログをどのような方法で扱っているのか、そして、その根底にあるグラニのポリシーとはどんなものだろう。
4. 各言語に広まったRx（Reactive Extensions、ReactiveX）の現状・これから
.NETから始まったRx（Reactive Extensions）が、なぜRxJavaやRxJSなど他の開発言語で人気を集めているのか。“ReactiveX”とは何か？ そしてRxは、これからどう進化していくのか。
