オープンソーステクノロジー勉強会第2回－開催のご報告－

2006年4月11日(火)、国際大学グローコムにて、第2回「オープンソーステクノロジー勉強会」が開催されました。今回もインターネット関連企業のエンジニアを中心に、前回を超える60人ほどが参加しました。

第一部では、オープンソースの汎用日本語形態素解析エンジンMeCabの開発者である工藤拓氏をお招きしました。日本語形態素解析の基礎から、MeCabの基本構造・アルゴリズムに関する説明など、実例を交えながら詳細に解説していただきました（発表資料はこちら）。

第二部ではグリー株式会社の小林一樹が、「NagiosとSNMPを用いたサーバ監視フレームワーク」をテーマに、GREE内でのオープンソースを利用したサーバー監視の仕組みなどについて発表いたしました。監視システムの構築の経緯や、現状の課題、今後の方向性ついてご説明しました。

（発表資料はこちら）。

懇親会にも40名の方にご参加いただきました。

勉強会も2回目となりまして、前回より多い60人の方にご参加いただきました。
来月の勉強会は、5月中旬を予定しております。近日ご案内を掲示いたしますので、ぜひとも奮ってご参加ください。

参加者からのご報告

参加者の皆さんのブログや日記のエントリーをご紹介します。こちらで確認し次第、随時更新いたします。今回の勉強会について書かれた方は、「オープンソーステクノロジー勉強会」という言葉を入れてご記入いただければ、追加いたします。

講演資料(1) MeCab: 汎用日本語形態素解析エンジン

podcast: 音声ファイル(mp3 36,438,552バイト)
RSSフィード(podcast対応)
講演資料: gree-study-20060411-mecab.pdf

はじめに

日本語をいかに機械に処理させるか 5年あまりの集大成として、ライフワークとして
日本語の解析の分野で仕事をしていることが多いので、その分野でのトークには慣れているが、一般のエンジニアには発表したことがないので緊張している

日本語形態素解析のアジェンダ

日本語について深く知っている必要はない、純粋に工学的な立場で、エンジニアリングとして触れる
MeCab の歴史、汎用テキスト変換ツールとしての MeCab について話していきたい

形態素解析の技術

日本語処理のための辞書の要件
- 単語の区切りが明確ではないので、どこまでが単語かわからない
- 単純な方法 (hash テーブル引き) だと大変時間がかかる
  - nDBM はそのため利用に適さない

辞書検索のためのデータ構造

TRIE (トライ)
対象文字列の先頭から木をたどっていく
さまざまな実装がある
- MeCab では Double Array-Trie を利用している。

Double-Array TRIE

BASE配列の n 番目の要素の値を基準に charcode を足したものを CHECK の参照オフセットとする
参照された CHECK の要素が n に等しければ、参照オフセットを n に代入する、
以上の繰り返し
探索が非常に高速
MeCab でも ChaSen でも使っている
欠点としてはテーブルが巨大
空き領域を探して埋めていくので構築が大変

あいまいさの解消

ヒューリスティックスには限界がある。
最小コスト法の採用
- 連接コスト(単語のつながりやすさ) および生起コスト(単語の出現しやすさ)
- この2つを各単語ごとに求めて、もっとも小さいコストになるような単語同士のつながりを作る
- Viterbi アルゴリズム
  - 複数ある組み合わせから、高コスト順に順次消していき、最後に残ったものを採用する
  - コストの決定
  - 人手ではかなり大変
  - 統計的手法を利用することが現在の流行
  - 大量の生テキストから推定
  - 生成コストは低い
  - 質に問題があるが、全文検索目的なら OK?
  - 正解データを人手で作る
  - 生成コストは比較的低い (専門家でなくてもよいので)
  - 主に利用されている方法
  - VisualMorph
  - 松本研で利用
  - Conditional Random Fields
  - 統計的コスト推定アルゴリズム
  - MeCab 0.9 より同封
  - ChaSen と比べて 1/3 程度のデータで有効に働き、高性能

オープンソース形態素解析器

JUMAN
- 松本教授によるprologプロトタイプ
- 妙木・黒橋氏にによるC実装
- 松本教授によるコスト推定
- 山下たつを氏によるパトリシアTRIEによる高速化
- 最近になって辞書の再編成機能などが開発されている
ChaSen
- JUMANからfork
- 浅原氏によるコスト推定法の研究
- 北内氏によるトライグラム拡張
Mecab
- ダブル配列による高速化
- 機能限定・シンプル
- 開発言語をC++
- オブジェクト指向
- ダブル配列はChaSenにバックポート
Sen
- MeCabのJava Port

汎用テキスト処理ツール

MeCab は日本語形態素解析器というだけではない
汎用的
テキスト⇒テキストの汎用変換ツール
- 仮名漢字変換
- ローマ字⇒ひらがな
- 文字コード変換
- 適切に辞書・コスト値を作れば実現可能
- 標準語⇔関西弁 (?)

MeCabの設計方針

辞書とシステムの完全分離
- 自然言語の複雑さは辞書・コストとして外部定義
システムは日本語を知らない
- ひらがな、カタカナの区別すらしらない
- 他の言語も辞書さえあれば解析可能
解析速度を犠牲にしない
- 事前計算はすべてやる
- 辞書やコスト値はすべてバイナリデータ
- ディスクの使い方は富豪的
機能の選別
- 前処理・後処理でできることはやらない
  - ChaSenの機能過多の反省
  - 代わりにAPIを充実(C/C++,Perl,Java,Python)
- 解析器にしかできない機能を提供
  - N-best解、制約付き解析、ソフト分かち書き
ソフト分かち書き（＝形態素解析/文字単位解析) / 2
- 形態素解析とn-gramは一長一短
  - 2つの立場を融合、単一化できないか？＝＞ソフト分かち書き
- 応用によって２つの立場を無段階に選択する
  - いいとこどり
汎用テキスト処理ツール
- 日本語形態素解析器ではない
  - 汎用的に作っている
- テキスト -> テキストの汎用変換ツール
  - 仮名漢字変換
  - ローマ字 -> ひらがな
  - 文字コード変換（ちと強引）
  - 適切に辞書・コスト値を作れば実現可能

MeCab の辞書

dic.csv
- 辞書定義
  - 単語、左文脈id、右文脈id、単語生起コスト、素性列（CSV）
amtrix.def
- 連接コスト定義
  - 左文脈id, 右文脈id, 単語連接コストの３列で構成
char.def
- 文字の定義
unk.def
- 未知語処理の定義
dicrc
- 出力フォーマットの定義

応用例

AutoLink
- 自動的にリンクが張られる機能
- dic.csv のみを使う
- コストは長いものから指数的に小さくなるように設定
  - 連接は使わないので matrix.def は不要

T9風予測入力
- 携帯テンキーの数字入力のみから入力語を推定
  - 各キーに割り当てられた行を元に単語を予測
  - 1681 -> おはよう
  - 241 -> くどう
  - ※T9風予測入力のデモ
  - ※アルファベット子音による予測のデモ
- div.csv
  - 入力は数字、文脈idはすべて
- matrix.def
  - wikipedia を mecab で解析した結果から、カタカナのつながりやすさをコスト化
- 日本語らしさのコスト化
  - デモンストレーション

汎用的利用例：素性フィールドの利用
- 辞書の素性はCSVなら何でも可能
- 単語に様々な付加情報を付与

まとめ

MeCabの技術
- 辞書引き
  - 通常のhashは使えない
  - TRIE
- 曖昧性の解消
  - 最小コスト法
  - 統計処理による正解データの推定
- 設計方針
- 汎用性
  - テキスト変換ツール
  - 意外な使い方

質疑応答

末端の探索が遅くなる原因は？
- =>配列の (CPU の) キャッシュに乗り切っていない部分については、検索が遅くなる
前処理をしているといったが、動作しているもののパラメータをいじるには？
- =>今のところ実現できていない。辞書をread onlyで読んでいるため。
スパムフィルタなどは動的でないとだめ？
- =>ある程度バッチでできるのでは
エンディアン依存性をなくすというTODOは？
- =>たぶんやらない。遅くなるため。mmap() して速度を稼いだりしているので、遅くなる
Debianでアーキテクチャ毎に辞書を作っていたら、苦情がでた。。encodingも辞書別に決まっている
- ＝＞MeCabのポリシー。高速性と、やれることはすべて前にやっておくというもの。今のところやる予定はない。
MeCabのゴールは？
- ＝＞どの言語でも解析できるようなフレームワークを作る。形態素解析だけと思われたくない。IMEとか他のものを作りたい。

講演資料(2) Nagios + SNMP を用いたサーバ検知フレームワーク

podcast: 音声ファイル(mp3 18,002,762バイト)
RSSフィード(podcast対応)
講演資料: gree-study-20060411-monitor.pdf

前振り

安定性を考慮して Nagios 1.x を利用

アジェンダ

前のフレームワーク、現在のフレームワークとの比較で話していく
サーバ
- Linux で合計、計70台
- ソフトウェアは Apache 1.3, MySQL 4.0.26, PHP 4.3.11...

前の監視フレームワーク

cron で sysmonitor.php を実行し担当に通知する
- プラグインで拡張可能
- 設定ファイルは簡単に書ける
- 問題点
  - 内部監視のみ
  - サーバがダウンしてもわからない
  - 外部監視は自宅サーバ
  - すべてを監視しようとすると複雑化する
  - 運用ルールやポリシーを徹底するのが大変

構築の際に考慮したこと

目的を明確にする。
運用ルール / ポリシーの設定
- アラートが必要な人員に最低限通知されるようにする
- できる限りオープンソースを活用
- 随時見直しが可能な拡張性

GREE監視フレームワークの特徴

内部と外部の両側から監視
外部監視の冗長化
拡張性
運用ルールの整備
シンプルで低コスト

全体的な構成

内部監視は SNMP と sysmonitor

なぜ Nagios と SNMP なのか

豊富な動作実績、ドキュメント
柔軟な設定および運用が可能
拡張性
オープンソース

AlertManager

通知キューを処理し、重複アラートをまとめたり、アラートレベルを決定する役割

Nagios プラグインの書き方

簡単
終了コードとステータスを示す文字列を標準出力に出力するだけでOK

課題と今後

障害検知までの時間を短縮
アラートフィルタの改善
メール以外の通知方法