AWS OpenSearchでkuromojiのユーザ辞書の検証をする手順
最近検索エンジン周りの検証をしていて、AWS OpenSearchと戯れていました。
余談ですが、昔ログ基盤としてElasticsearchをそこそこヘビーユースしていた時代もあったのですが、今回n年ぶりに触っていたら色々と忘れていたり進化していたりで触ってないと忘れるなっていうのを身を以て体験しました。
今回は小ネタで、OpenSearchでkuromojiの辞書整備をどんな感じでやっていったかを書き記しておこうと思います。 ※個人ブログの更新は実に2年ぶり！！
この記事はコネヒト Advent Calendar 2021の17日目の記事です。
OpenSearchで検証してる時の個人的な感想
- OpenSearch自体は公式ドキュメントはしっかりしているのだが、webで検索しても中々いい記事にたどり着けないというのが色々と調べていたときの感想。
- Elasticsearchの7.1をforkして作られているという話なので、使い方みたいな部分はElasticsearch7.1以降の記事を参考にするとOpenSearchでやりたいことに近づけたという印象(あくまで個人の印象)
- 特に下記の@johtaniさんのブログには助けられました。
OpenSearch Dashboard
OpenSearchにはKibanaライクなOpenSearch DashboardというGUI管理画面があります。
CURL経由でJSONを投げつけての検証は中々辛いものがあるので、今回はこちらのDevToolsを使ってkuromojiのユーザ辞書の検証を行いました。 ※kibanaのDev Toolsとほぼ一緒の使い勝手です。
ユーザ辞書でやりたいことのおさらい
ユーザ辞書でやりたいことはシンプルで、トークナイザーの標準辞書だとうまくあたらないワードをユーザ辞書を使うことで当てることです。
例えば、「抱っこ紐」と検索した時に、標準のkuromoji_tokenizer だと「抱っこ」「紐」に単語分割されトークン化されてしまうため、「抱っこ」「紐」それぞれにマッチする文章がヒットしてしまいます。これを「抱っこ紐」というユーザ辞書を登録することで単語分割時に「抱っこ紐」というトークンにすることで、「抱っこ紐」というワードにヒットする文章を検索することが可能になります。
下記のelastic社のブログで詳しく解説されていますが、検索エンジンを考える上で、再現率(検索モレが少ない)と適合率(ノイズが少ない)のトレードオフが大事になってきますが、今回の辞書のアプローチはノイズをへらすために辞書を整備するというアプローチになります。
すべてを辞書で賄うことは出来ないので、形態素解析でノイズを減らしつつ、n-gramで検索モレを減らしていくアプローチが良さそうです。(検索の専門家ではないのでこのあたりは色々試行錯誤しながらベストなパターンを見つけていきたいです)
kuromojiユーザ辞書を検証しながら作っていく手順
今回の検索エンジンの検証では、日本語を扱う必要があったのでkuromojiを使いました。 ※OpenSearchはsudachiは現時点ではサポートされていません。
ここから、kuromojiのユーザ辞書を整備していくために今回取った手順を説明します。 簡単にいうと、kuromojiの標準トークナイザーで該当単語をがどうトークン化されるかを調べて、意図せぬ分割がされていたら辞書化するというアプローチを取りました。
①kuromojiの標準トークナイザーでどのようなトークン化されるかを確認する
## 標準辞書のkuromoji_tokenizerで引く
GET _analyze
{
"tokenizer": "kuromoji_tokenizer",
"char_filter": {
"type": "icu_normalizer",
"name": "nfkc",
"mode": "compose"
},
"filter": [
"kuromoji_part_of_speech",
"kuromoji_stemmer"
],
"text": "抱っこ紐で生後6ヶ月の赤ちゃん"
}
結果: 「抱っこ紐」が「抱っこ」「紐」だったり、「生後6ヶ月」が「生後」「6」「ヶ月」に分割されています。
{
"tokens" : [
{
"token" : "抱っこ",
"start_offset" : 0,
"end_offset" : 3,
"type" : "word",
"position" : 0
},
{
"token" : "紐",
"start_offset" : 3,
"end_offset" : 4,
"type" : "word",
"position" : 1
},
{
"token" : "生後",
"start_offset" : 5,
"end_offset" : 7,
"type" : "word",
"position" : 3
},
{
"token" : "6",
"start_offset" : 7,
"end_offset" : 8,
"type" : "word",
"position" : 4
},
{
"token" : "ヶ月",
"start_offset" : 8,
"end_offset" : 10,
"type" : "word",
"position" : 5
},
{
"token" : "赤ちゃん",
"start_offset" : 11,
"end_offset" : 15,
"type" : "word",
"position" : 7
}
]
}
②ユーザ辞書を使ってanalyzerを登録するために、擬似的なdemo_custom_dicというインデックスを作成
- user_dictionary_rulesでユーザ辞書を定義しています
- ユーザ辞書はインデックス作成時に登録されるので、ワードを追加するときは一度
DELETE demo_custom_dicでインデックスを消してからサイドインデックス登録するという手順を繰り返します。
PUT demo_custom_dic
{
"settings": {
"index": {
"analysis": {
"tokenizer": {
"kuromoji_user_dict": {
"type": "kuromoji_tokenizer",
"mode": "search",
"discard_compound_token": true,
"user_dictionary_rules": [
"朝ごはん,朝ごはん,アサゴハン,カスタム名詞",
"抱っこ紐,抱っこ紐,ダッコヒモ,カスタム名詞",
"生後6ヶ月,生後10週,セイゴジュッシュウ,カスタム名詞"
]
}
},
"analyzer": {
"demo_analyzer": {
"type": "custom",
"tokenizer": "kuromoji_user_dict",
"char_filter": {
"type": "icu_normalizer",
"name": "nfkc",
"mode": "compose"
},
"filter": [
"kuromoji_part_of_speech",
"kuromoji_stemmer"
]
}
}
}
}
}
}
③demo_custom_dicインデックスに登録したdemo_analyzerを使ってどのようにトークン化されるか確認
## ユーザ辞書を登録したkuromoji_tokenizerで引く
GET demo_custom_dic/_analyze
{
"analyzer": "demo_analyzer",
"text": "抱っこ紐で生後6ヶ月の赤ちゃん"
}
結果: 「抱っこ紐」が「抱っこ紐」だったり、「生後6ヶ月」が「生後6ヶ月」にとユーザ辞書がトークン化時に考慮されて意図した分割がされています。
{
"tokens" : [
{
"token" : "抱っこ紐",
"start_offset" : 0,
"end_offset" : 4,
"type" : "word",
"position" : 0
},
{
"token" : "生後6ヶ月",
"start_offset" : 5,
"end_offset" : 10,
"type" : "word",
"position" : 2
},
{
"token" : "赤ちゃん",
"start_offset" : 11,
"end_offset" : 15,
"type" : "word",
"position" : 4
}
]
}
このようにして実際にどのようにトークン化されるかを確認しながらユーザ辞書を整備しています。 ある程度の辞書が出来たら、OpenSearchではパッケージという仕組みを使ってs3に保管したファイルをユーザ辞書やシノニム、ストップワードに使うことが出来るのでそちらを使って管理するのがよさそうです。
こちらも検証した感じ下記ドキュメントの通りにやれば簡単に出来ました。
2019年を振り返る(機械学習の世界に足を踏み入れた)
年末で、ちょうどアドベントカレンダーの枠があったので今年一年の活動を振り返っていこうと思う。
この記事はコネヒト Advent Calendar 2019 21日目の記事です。
2019年は結構自分の働き方が変わった一年でもあったので、下記2点を中心に書いていく。
- 機械学習の世界に足を踏み入れた
- アウトプット中心の活動ログ
機械学習の世界に足を踏み入れた
組織の大きな変化もあり、今年から業務として機械学習に取り組んでいる。(元々興味はあったのでチャレンジするいい機会に恵まれたというのが正直なところ)
ここでは、機械学習関連のものだけに絞って時系列でどんなことをやっていたのかを振り返ろうと思う。
1〜3月
当時のCTOの @tatsushim がPythonによるはじめての機械学習 という本を執筆しており、そのレビュワーとしてこの本を通じて機械学習を学び始めた。
この本は、機械学習の初学者が理論よりもまず先に実際に手を動かしてみて機械学習とはどのようなものなのかを体感することに重きが置かれている。 実際にこの本の内容を、全て手を動かしながら疑問点を執筆者である @tatsushim に直接質問しながら「データ準備」→「前処理」→「学習」→「予測」の一連の流れを学習出来たのは後にとても役立ったなと今振り返ってみて思う。(執筆者に直接質問出来る環境はとても貴重であった)
この時点ではなんとなく機械学習がどんなものなのかわかったというレベルで、まだ自分でモデルを作ったりということについては正直想像がついていなかった。
4〜9月
新しい期が始まり、インフラ・MLチームが誕生し、実際の業務で機械学習に携わっていくようになった。 主に、この期間にやっていたのは3月からコネヒトにジョインしてくれた @takapy0210と3人で、これまでEC2で運用していてモデル更新もしてこなかった機械学習基盤を定期的なモデル更新が出来るような形にリプレイスするというプロジェクトだった。
ここでベースとなるアーキテクチャをしっかり作っておくことで、下期以降の機械学習基盤の出足を早く出来ると考え整備をした。
ざっくりと書くと、
- 基盤をEC2からSageMakerにリプレイス
- アプリケーションのコンテナ化(Flask APIと前処理のバッチ)
- Glueを使ったデータ準備フェーズの簡素化
- @takapy0210が書いてある記事が詳しい AWS Glueを用いてETL環境を構築したお話（RDS for MySQL → S3)
このフェーズではML Ops的な側面が大きかったので、これまでのインフラエンジニアとしてのキャリアがだいぶ役に立った。 また、実際に機械学習が動いてる基盤をリプレイスしたことでより具体的なイメージが湧いた点は大きかった。
また、チーム力強化を目的に輪読会も始めた。 この輪読会がMLエンジニアとしてのスキルアップにとても役立った。
お題の本: Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎
@takapy0210と相談して、毎回範囲を決めてこの本をJupyter Notebookで全て写経し、疑問点や気付きを輪読会で発表しあうという形式をとった。 これが後にとても役立ち、pandas,numpy,scikit-learnの使い方が手に馴染んだのと、様々なアルゴリズムを実際に手を動かしながら体験出来たのが大きかった。(この本はディープラーニング系のアルゴリズムの解説はあまりないのでそこは後々キャッチアップしていこうと思う)
この本を読んでいくにあたりPythonによるはじめての機械学習 で機械学習のアウトラインを最初に掴んでおけたのは大きかった。
他にも、
- ハンズオン形式で実際のデータを元にNLPのタスクをやったり
- SIGNATEの練習問題コンペに参加して結構いいスコアが出たりSIGNATEの練習問題コンペで 57位までスコアを上げた話
と徐々に課題を機械学習を使って解決する手段が自分なりにつかめてきた半年だった。
10〜12月
上期で一通りの機械学習基盤が整ったので、下期はサービスの課題を機械学習の力で解決していこうと攻めの姿勢でプロジェクトを進めている。
自分も、NLPの多クラス分類の課題に今チャレンジしており、うまく進めばどこかで紹介出来ればと思っている。
機械学習プロジェクトを実際に進める上で、下記が大事だなとここ最近思っているので書き留めておく。
- 課題設定
- 他のチームとの期待値調整
- AIと聞くと期待値はすごく上がるわけだが現実的な落とし所をしっかり設定する
- 精度は導入してから改善していけるというのもポイント
- ドメインの理解
- これは特徴量作成や選定にあたり必須になる
- やってみないとわからない部分が多い
- ある程度の精度はオフライン検証で出来るが、実際のユーザの行動は出してみないとわからない部分が大きい。
- ABテストまで気軽にチャレンジ出来る環境や周囲のサポート、そんな環境を作るための期待値調整が大事なんではないかと思っている。
そして、今はこの本を輪読している。自分はNLP関連を強化していきたいというのと、まだあまりキャッチアップ出来ていないディープラーニング関連の話も解説されており、今解いている課題にも近しいということでこの本になった。
そんなわけで機械学習エンジニアとしての第一歩を踏み出したわけであるが、自分としては久々の全く新しいチャレンジでワクワクしていて楽しいというのが正直な感想である。文系の自分にとって難しい数式が理解出来るかというとそうではないんだけど、そんな数%の精度向上を求められる世界の前段くらいまではこのまま突き進んでいけるんではないかと思っている。
インフラ分野に関しては、これまでの勘が働いてどんな課題もある程度なんとかなったりするが、別分野になると全く鼻が効かず悪戦苦闘しているが、そんな悪戦苦闘も久々で楽しかったりする。 一人で、今の状態までなれていたかというとそれは無理な話なので、優秀なチームメンバの @takapy0210 には本当に感謝している。
2020年は、機械学習分野でも成果を出していきたいと思っている。
アウトプット中心の活動ログ
後半は、今年一年の活動を外部へのアウトプット中心に振り返っていこうと思う。
1月
日経SYSTEMSへの寄稿がきっかけで、日経主催のイベントで話す機会をいただいて喋ってきた。
2月
Auroraのカスタムエンドポイントの検証をしていて記事を書いた。 ただ、後に色々と課題があり現在まだサービスには投入出来ていない。
会社のメンバと共著で、下記のPHP本のインフラ部分を執筆した。 雑誌の執筆とは違い本の執筆は本当に大変だった。(自分はページ数少なかったが他のメンバは本当に大変そうで頭が下がる思いだった)
TECHNICAL MASTER はじめてのPHPプロフェッショナル開発 PHP7対応 | 伊藤 翔, 金城 秀樹, 高野 福晃, 永井 勝一郎 |本 | 通販 | Amazon
3月
比較的Fargateを早い段階でサービス投入していたので、JAWS コンテナ支部で喋ってきた。 当時ECS+FargateをFargateと表現するような風潮があったのでそうではないよね的な話をした(今はEKS for Fargateも出てそのような話は聞かなくなったが)
4月
ちょっと変わり種で、imgixという画像サイズを動的に変換したり柔軟な加工が出来るCDNを導入したのでそれについて書いた。
6月
新規サービスのECSへのデプロイをcodebuildで行ったのでそれについてまとめた。 肝となるローカルレイヤキャッシュにホストガチャ的な要素はあるが、この構成は中々良くて新規サービスはだいたいこのフローに則って運用している。
10月
AWS DevDay Tokyo 2019で、CfPが通ったので喋ってきた。 主にAWSを使ったサーバレス中心のバッチアーキテクチャの話をしてきた。 会場が超満席になっておりとてもありがたいなと感じたことを覚えている。
11月
上でも話した機械学習のテストコンペでスコアをかなり上げれた経験について話した。 機械学習関連は初めての登壇だったので、何を話したらいいかわからず資料作りに悪戦苦闘したことを覚えている。
12月
今年ECS関連で取り入れたアップデートについてまとめた。 今年は、機械学習に個人のリソースをだいぶ割いたので小物感が強く来年はもう少しインフラ分野もチャレンジしていきたいと思っている。
ということで駆け足で2019年を振り返った。 今年は機械学習関連のインパクトが強く、久々にエンジニアとしての成長を実感出来た1年だった。 来年は、プロダクトにそれらを還元することを目標にしつつインフラ面でも攻めていこうと思う。
2018年をアウトプット中心に振り返る
3年半くらい振りの個人ブログ。年末でちょっと時間が出来たので今年一年をアウトプット中心に振り返ってみる。 こうして振り返ってみると登壇が多くリアルな外との接点が増えた一年だったなと思う。 また、内容からも2年前くらいまではガリガリオンプレを触っていた自分のスキルセットがだいぶクラウド寄りになってきたなということを感じる。コンテナとの出会いが大きくいわゆる自分が得意としていた領域が抽象化されても、それを動かす基盤をしっかり把握しながらうまく整えていったりとうまくシフトチェンジ出来ているかなと感じる。
登壇系
これまでで一番大きな規模の会場での登壇を何回かすることが出来て、非常にいい経験が出来た一年だった。
1月 MasterCloud #9 新春クラウドLT大会
クラウドに関することなら何でもありという回だったので、「オンプレ思考からクラウド思考へ」というタイトルで、クラウドでシステムを作っていくにあたり自分の経験から感じていることをまとめた。
5月 Redash Meetup #2
主催の有田さん(@ariarijp)に声をかけていただき、コネヒトで進めたRedash導入とデータ民主化の話をさせていただいた。
6月 AWS Summit Tokyo 2018 「Startup Architecture of the Year 2018」
AWS Summit Tokyoの一枠で行われた3分間のピッチコンテストで、CTO100人の前でWell-Architectedなシステムアーキテクチャをプレゼンするというものだった。自分はコンテナベースでの運用の優秀さについてプレゼンした。コンテスト形式で入賞は出来なかったが、今までの登壇とはひと味違った刺激のあるいい経験をさせていただいた。 codezine.jp
チームメンバに事前にチェックしてもらったのもあり当日は満足出来るプレゼンは出来たので感謝。
10月 JAWS-UG横浜 #13 Tips in Advanced
何度か登壇したり参加させていただいているJAWS-UG横浜で、実業務で取り組んでいたRDS for MySQLからAuroraへのメインDBの移行について発表してきた。
12月 Japan Container Days v18.12
初めてCfpというものを出して、幸運にも通過することが出来たので喋ってきた。k8s全盛のコミュニティの中で、自分はその前のフェーズのアプリケーションのコンテナ化がチーム開発にもたらしてくれる変化を中心に話してきた。強そうなセッションが同じ時間帯に多く人が来てくれるか不安もあったが、7,8割くらい埋まってくれて安心したのを覚えている。そして、良いフィードバックもいただいたのでこれからコンテナ化していくといった人たちに事例を伝えるという一定の役割は出来たかなと思う。 このイベントは、参加者としても色々なセッションを聞きk8sやCloudNative周りのコミュニティの熱気を実感出来て非常に刺激のあるイベントで楽しかった。
ブログ・執筆
ブログは会社の技術ブログしか書いてないが、計6本なので2ヶ月に1本は書いた計算になる。 最近初めて会う方にもコネヒト開発ブログでECSとかAWS関連の見ましたみたいな話されることが多くなってきたので、この勢いは大切にこれくらいのペースは維持していきたいなと思う。
また、初めての執筆の機会もいただきCTOの島田と一緒に日経SYSTEMS 11月号に「ママリが実践する コンテナ移行の正攻法」という内容で寄稿した。
ママリが実践する コンテナ移行の正攻法 | 日経 xTECH（クロステック）
また、この寄稿つながりで来年1月に日経さん主催の「IT インフラSummit2019」での登壇することになった。
ITインフラSummit 2019｜日経 xTECH主催セミナー
来年は、また新しいチャレンジをして学んでいこうという予定なのでインプット多くなりそうな一年な気がしてるが、程よく アウトプットもしていこうと思う。
はじめてansibleを触って、playbookを実行するまで
ansibleよりChef派でしたが、エージェント要らなかったり気軽という評判を聞きつけて、今度リリース要件にはansibleがよさそうなのでとりあえず使ってみた。
環境
ansibleサーバ:192.168.50.5 プロビジョン対象:192.168.50.6
EPELのリポジトリを追加してインストール
$ sudo rpm -ivh http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm を取得中 警告: /var/tmp/rpm-tmp.sZnYCN: ヘッダ V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY 準備中... ########################################### [100%] 1:epel-release ########################################### [100%] $sudo yum install -y ansible
設定ファイル場所とか(デフォルトのパス)
/etc/ansible
--ansible.cfg
--hosts
--roles
--各playbookを置く??
事前準備 対象サーバに事前にsshの鍵なし認証を出来るようにしておく
秘密鍵作って公開鍵を相手サーバに登録する 下記参照で!! http://qiita.com/nagais/items/a4e3d7ef2aba43bb0e4d
初めてのansibleコマンド実行まで
hostsに対象マシンを追加
[グループ名]でグループ定義らしいのでとりあえずtestgrpを作る
# This is the default ansible 'hosts' file. # # It should live in /etc/ansible/hosts # # - Comments begin with the '#' character # - Blank lines are ignored # - Groups of hosts are delimited by [header] elements # - You can enter hostnames or ip addresses # - A hostname/ip can be a member of multiple
[testgrp] 192.168.50.6
ついに初めてのansibleコマンド!!
-mオプション
引数でモジュールを指定するらしいので、まずはテスト用に標準で用意されているpingモジュールを試してみる！
$ansible testgrp -m ping
192.168.50.6 | success >> {
"changed": false,
"ping": "pong"
}
-aオプション
指定したコマンドを対象ホスト上で実施してくれる
$ansible testgrp -a "/bin/pwd" 192.168.50.6 | success | rc=0 >> /home/vagrant
ついでに、初めてのplaybookも実行してみる
やりたいのは、新規リリースサーバの手順をcode化することなので、Chefでいうレシピ的なものという噂のplaybookを使ってみる。
どこにplaybookを置くのが最適なのかはわからなかったので、とりあえず/etc/ansible配下においてみた。
かなり簡単だけどbind-utilsをインストールして、yahoo.co.jpを引いてみるplaybook
- hosts: testgrp
remote_user: vagrant
sudo: yes
tasks:
- name: install bind-utils
yum : name=bind-utils
notify: dig test
handlers:
- name: dig test
command: /usr/bin/dig yahoo.co.jp
で、実行
全部通った。 すごい簡単というか、Chefの時はchef-soloで初回実行するまでに、結構時間かかったが、ここまで1時間程で。
所感
想像以上に障壁が低かった。ここらのツールは冪等性が最重要だと思ってるので、どこまでコマンド類が揃っているのかはまだまだわからないが、プロビジョニングはplaybookでやって、複数台で同じコマンド打ちたい時は、ansibleコマンドをグループに対して実行とかやるとかなり使えそう。 どうやら、web見てると出来ないと思ってた、ファイルのプッシュとかも出来そうなのでかなり楽にプロビジョニングの土台出来そう！ 只、ディレクトリ構成とか細かいとこは全然わかってないので、もう少し触ってみようと思った。
※Qiitaに投稿か、ブログにしようかいつも迷うな。。。
参考
http://knowledge.sakura.ad.jp/tech/3124/ http://docs.ansible.com/ansible/playbooks_intro.html
【レポート】SmartNews Tech Night Vol.2 ~クラウド事業者に就職する以外の インフラエンジニアの生きる道~
久々に面白いイベントだったので、メモを公開。
感想
メモったことそのままで長くなるので最初に感想だけ。 かなり釣り気味のタイトルでしたが、インフラエンジニアがいっぱいいて楽しいイベントでした。 トークしてた人たちが、有名とこの人達だったのでオンプレを否定するような空気は全くなかった。
印象に残ったのは下記の部分
インフラエンジニアという括りはもうない(得意な技術領域の異なるエンジニアがいるだけ)
クラウドで環境作るのは簡単だけど、中身を知らないと存在価値ない(裏がどういう仕組みかを知っているかとか中身を知っているのは強みになる)
世間的にアプリエンジニア・インフラエンジニアと言われている人の日常業務を比較すると実はあまり変わらなくて得意な領域が違うだけという世界
インフラの仕事(サーバ構築,適切な監視,必要な検証,障害対応)は変わらないが、ツールのコモディティ化(Chef,Fabricとか)により、やり方は変わっている
新サービスはクラウドでの方針、オンプレで育ったサービスはノウハウ・費用をどう考えてもオンプレが優位(グリー、CA,DeNA3社とも同じ見解)只、クラウド化を検討しないわけではなく明確な優位があれば常に検討はする。
監視ツールの領域はみなさんかなりSaasを使っている(規模が大きいのでオープンソースをそのまま使えず、自分達で運用するよりそのサービスに全力を使っている会社に任せる方が正しいという考え方) DataDog,pagerduty,logentriesとか
アラートやり取りをslackに集約(これはメール、これはチャットとかでなく全て集約すると全体見えるしスピード上がる)
クラウドだとまず第一にみんなAWS使ってるからやはりスタンダードなのは間違いない。(只、各社得意分野違うので、GCEとかSoftLayerとか国内クラウドも組み合わせる)
事業会社のインフラと呼ばれる人達は、サービスだけでなく社内も一緒に見ているのはどこでも一緒だった！
生き残る道
- 事業会社のインフラなら、サービス目線で何でも出来る中で特定の得意技術をもつ人としてやっていく(RPGのステータスで一つとがって他は平均的みたいのが理想)
- ミドルの一製品を極めたかったら、mysql→AWSでRDSの人になるとかそういう道はあり
- 既得権益を守ろうとするのではなく、世の中の変化に対応して自分達のサービスにあった形で考えや行動を変えていくのは大事
- 覚えた技術は裏切らない
インフラ専任エンジニアが一人も居ないSmartNewsにおけるクラウド活用法
SmartNews 大平さん(この人はアプリエンジニア)
- サイバー→LINE→smartnewsと渡り歩く
1000万ダウンロード 日米 アルゴリズムで記事の選定をしているらしい
- なぜインフラ専任がいないのか
少人数・クラウド活用している
エンジニアの数の推移 2012 1人 2013 5人 2014 15人
大事なところにだけ集中する
→サーバ、ネットワーク、データセンタの管理から開放される APIでプログラマブルに管理 スタートから現在まで全てクラウド上にある
運
なぜフル活用出来たのか クラウドサービス向けのアーキテクトになっているから タイミング良くAWSが整ってきて料金も下がった
向かないケース
write heavyな処理 over10Gbpsトラフィック リアルタイム性 低レイヤーでカリカルのチューニングやカスタマイズが必要なもの LINEとかは向かない
仮想環境の限界はある ・ネットワーク最適化(経路とか) ・ioDrive
向くケース
ディスクアクセス少ない トラフィック少ない とか向かないケースと相反するケース
smartnewsのシステムは?
・疎結合なアーキテクチャ ・バックエンドは非同期多様 ・ディスクアクセス減らす為、mem多様 →永続ストレージへは遅延書き込み ・キャッシュを多様している(自作のエンジンとフレームワーク)
どのようにAWSでサーバを管理??
・provisioning tool使う
chefやfabricで誰でも透過的に使えるように 各エンジニアが一定のルールにもとづいてレシピ書く
saasを使って運用系のサーバの運用がない姿勢
saasを組み合わせて自前ではやってない DataDog 監視ツール(nagiosとか) newRelic プログラム側の pagerduty (通知系) logentries (es+kibana) chartio クラウド版のBIツール slack 監視アラートを集約 →情報の分断を防ぐために相談もアラートも全てslackに集約 →ビジネスの人も チラ見するだけで色んなチームの状況わかる →情報をAPUを使ってプロフラマブルに組み立てる
インフラエンジニアとは。。
設計・構築・運用する人
ミドルから下見る でもsクラウド出てきて、OSまではクラウド事業者がカバーしてきた
インフラとアプリのレイヤが重なってきてきた
smartnews アプリ・インフラもやってる業務は同じで、得意領域が少し違うだけ →そこには境目はない
これからのインフラエンジニアについて考えていること
グリー 梶原さん
社内インフラ・サービスインフラ共に見ている
・新サービスはAWSでやってる
グリーの事例
情報システムのインフラ
業務アプリ オンプレ ファイルストレージ クラウド・ストレージ →latencyとセキュリティの問題(機密情報どこまでおけるか)で一部オンプレ
サービスインフラ
オンプレ AWS Openstack(オンプレクラウド) ミックスで使っている
オンプレ
ほぼ物理 ラックとサーバの最適な配置は課題 複数DCで相当数サーバを管理(DR考えつつ)
OpenStack 2013
仮想化でリソースの有効活用 プライベートクラウド 本番環境・開発環境で利用 ポータル作って開発環境を楽に使えるように提供
AWS 2014〜
新規にリリースするサービスはAWS利用と決めてる
ハイブリット
DirectConnectを使って組み合わせる 保守切れのタイミングで考える 在庫を持ちたくない特殊なハード ピークとオフの差が大きいサービス
やりたい事
GCP,Softlayerを使いハイブリットクラウドに拡大 Openstackのコンテナ対応 Whiteboxスイッチ
選定基準 ・コスト 大規模調達するとまだまだ物理は安い 年に数会値下げはあるAWS
・メンテナンスのコスト サービスによってはメンテナンスの調整コストが高いものがある AWSのメンテナンスは結構あるので、それに耐えれないサービスはやらない
いいとこ
デリバリスピードはやい 不要なときにすぐすてれる
課題
ブラックボックスの為手が出せないレイヤがあり何か起きた時のインパクトが大きい
障害→サポート連絡→繰り返し、、 本質にたどり着くのに時間かかる →自分でログインしたりハードみたりというのと比較すると辛い 落ちて当然のアーキテクチャでアプリが出来てないので辛くなるとこがある（オンプレ用）
saasツールの利用も増えてきた
pagerduty datadog sumologic
これからのインフラエンジニア
サーバアプリ開発 サーバ運用 アプリ運用 ソースコードまでみてトラブルシュート DB NW DCやNWの設計
クラウド化進むとどのレイヤーも影響を受けかねない
クラウドに限った話ではないが変化を許容して柔軟に対応する事が重要
これから起きること 原因わからず負荷上がったからサーバ追加しよう
ビジネス的にはOK エンジニアリング観点はNG
何かわかんないけどioDrive入れたら早くなった
クラウドで運用は楽になるけど、これまで大変だった事がブラックボックス化され知識を得る機会がなくなってきた、 中身を知らないのは危険なことなので、競争力をつけるためにブラックボックスの中の知識をしっかりつける
要は使うのは簡単だけど、中身を知らないと存在価値ないという話
インフラエンジニアってなんでしたっけ
サイバーエージェント 桑野さん
web系インフラエンジニアの話
新サービスはほぼクラウド
でもDCがある ある程度の規模だとサーバ単価としてのコストは安い &ノウハウもある
やってること サーバ構築 適切な監視 必要な検証 障害対応 →クラウド時代になっても変わらない 只、やり方が変わっている
コード化する為のツールのコモディティ化
手で自分では構築しない 基本的な部品のAPI化 スピード感ましてキャッチアップが必要
なんをするにもコード化なので、 コードを書く必要に迫られる事が多くなっている
コード化出来る土壌が整っている 仕事のやり方が変わっている
なんかが起きた時の切り分けの手段を多く持っている&出来る →これはおおきなスキルでいらなくならなくないか?
エンジニアの壁が薄くなっている 有限なパラメータをどう振り分けるか →周辺知識は伸ばしていきながら得意分野は伸ばす
サーバの負荷抑える あフォーマンス上げる 出来るだけコスト
結局は事業で御飯を食べているので、事業そのものの成長を妨げない 成長のスピードを上げる 技術を諦めることもある
インフラエンジニアという単語に悲観せずにやる 覚えた技術は裏切らない でも変化を避けることは出来ない
物理を握った人が変化を嫌い、 守りに入った時に既得権益感が出て、事業のスピードに影響 →調整・調整になりがち
コストセンターだけじゃないという事を
インフラエンジニアというくくりはもうない 得意な技術領域の異なるエンジニアがいるだけ
http://www.slideshare.net/akuwano/ss-47049999
トークセッション インフラ界のドン達に若手気鋭のエンジニアが切り込む!斬!
SmartNews 坂本さん(モデレーター) SmartNews 大平さん CyberAgent 桑野さん DeNA 小野さん GREE 梶原さん
特徴を活かしてつなぎこむ GCP,AWS,Softlayer
オンプレで育ってきたものに関してコスト逆転しないとオンプレをクラウドに移行はね。。 便利なものは使うけど、オンプレのノウハウもあるから移行コストは高いかな。
正直試算は難しい。。
サイバー 課金部分は出さないけど他はだしていけないものはない という認識
クラウド、セキュリティの壁はある。。 →今作り上げたものがあるから → 新規サービス、ゲームはAWSは共通認識でした。
監視サービスを本気でやっている人達に、片手間でやる監視ツールでは勝てないからsaasを使うのは正しい →ニッチなところにはておどかない
どこに興味を持って何をやっていきたいかを突き詰める smartnewsも社内インフラもある
SmartNewsさん素敵な面白いイベントをありがとうございました。
オフィス見学も出来たし。(ぶれぶれ。。)
Elasticseach1.4にアップデートしたらkibana3からつながらなくなりはまった件
Elasticsearchを1.4にアップデートして、kibana3からアクセスしようとするとkibana3上で下記のようなエラーが出た。
Please ensure that Elasticsearch is reachable from your system
サーバ上で、curlではアクセス出来るし、自分のマシンからelasticsearch-headでもアクセス出来るのでElasticsearch自体は確実に動いている。。
curl -XGET http://localhost:9200
どうやら、kibana3からElasticsearch1.4を使うためにはkibanaのアップデートとelasticsearch.ymlへのパラメータ追加が必要そうなので下記を実施
①最新版kibanaをダウンロードして、ドキュメントルート配下とかに設置
kibanaを最新版(この時だと3.1.2)にするとkibana3側でもっと親切なメッセージが出る。 Elasticsearchが落ちているか、パラメータを追記せよと書いてある。
②Elasticsearchにパラメータを追加 このページのままですが、下記を追加
http.cors.enabled: true http.cors.allow-origin: "/.*/"
無事接続出来た。 テスト環境のElasticsearchをバージョンアップしたけど、kibana3からのアクセスではまるとは思わなかったのでメモとして。。
Elasticsearchで既にあるインデックスのスキーマを変更する方法
プロダクション環境でElasticsearch+kibana(fluentd)でログ可視化運用をしてみてわかった事でElasticsearchのマッピングについて記事を書いたところ、下記のようなツッコミをいただいたので実際に試してみた。
@johtani ありがとうございます。試してみましたが、APIでindexに対してマッピング追加出来ました。テンプレート+APIで当日分のマッピング追加すれば無駄データは出来ないですね！後で追記しときます。
— shnagai (@shnagai) December 22, 2014
内容は、新しいフィールドが追加される時に、事前にスキーマ定義しないと型がStiringのanalyze(分かち書きあり)にされるので、事前にテンプレート作りましょという内容を書いたのですが、既存のインデックスについてもフィールドのスキーマ変更出来るという事でした。
今回の例では、[c-ip]というフィールドがdynamic_templatesでnot_analyzedが定義されていますが、このフィールドにmulti_fieldを使ってanalyze(分かち書きあり)のドキュメントも追加してみたいと思います。
まずは既存のスキーマ確認
$ curl -XGET 127.0.0.1:9200/testindex/rs/_mapping?pretty
{
"rs" : {
"dynamic_templates" : [ {
"string_template" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "string"
},
"match" : "*",
"match_mapping_type" : "string"
}
} ],
"_source" : {
"compress" : true
},
"properties" : {
"@log_name" : {
"type" : "string",
"index" : "not_analyzed",
"omit_norms" : true,
"index_options" : "docs"
},
"@timestamp" : {
"type" : "date",
"format" : "dateOptionalTime"
},
"c-ip" : {
"type" : "string",
"index" : "not_analyzed",
"omit_norms" : true,
"index_options" : "docs"
}
}
}
}
マッピング更新APIを使って、c-ipフィールドをmulti_fieldにスキーマ変更
ana.c-ipで分かち書きされたドキュメントを検索出来るようにする
curl -XPUT 127.0.0.1:9200/testindex/_mapping/rs -d '
{
"properties" : {
"c-ip" : {"type":"multi_field",
"fields":{
"c-ip":{"type":"string","index":"analyzed"},
"full":{"type":"string","index":"not_analyzed"}
}
}
}
}'
変更後のスキーマ確認
変更後のスキーマを確認すると[c-ip]がmulti_fieldに変わっています。
#この変更は、次から投入されるドキュメントに対して有効になりますが、すでにインデックス上にあるドキュメントは変わらないので要注意です。
$ curl -XGET 127.0.0.1:9200/testindex/rs/_mapping?pretty
{
"rs" : {
"dynamic_templates" : [ {
"string_template" : {
"mapping" : {
"index" : "not_analyzed",
"type" : "string"
},
"match" : "*",
"match_mapping_type" : "string"
}
} ],
"_source" : {
"compress" : true
},
"properties" : {
"@log_name" : {
"type" : "string",
"index" : "not_analyzed",
"omit_norms" : true,
"index_options" : "docs"
},
"@timestamp" : {
"type" : "date",
"format" : "dateOptionalTime"
},
"c-ip" : {
"type" : "multi_field",
"fields" : {
"ana" : {
"type" : "string"
},
"c-ip" : {
"type" : "string",
"index" : "not_analyzed",
"omit_norms" : true,
"index_options" : "docs",
"include_in_all" : false
}
}
}
}
}
}
簡単ですが、@johtaniありがとうございました。
