こんにちは、LINEでGame Platformを開発している 趙 です。 この記事はLINE Advent Calendar 2016の9日目の記事です。 LINE Game Platformでは分散型でスケーラブルな高速データベースであるHBaseをメインストレージの一つとして使っています。HBase運用における問題のひとつは、cross row, cross tableトランザクション処理機能がない事です。Client Faultなどが起こった時の対応が難しいです。(例えば、HBaseにテーブルAとBがあり、ABの順番にデータを処理する場合、もしAの挿入の後にBの挿入に失敗した場合、データ不整合が起きます) HBaseは幾つかの単行atomic apiを提供します。(HBase versionによって違うところがあります) 複数cellに対してgetまたmutation操作 CAS(コンペア・アンド・スワップ) API checkAndMutate incrementColumnValue トランザクション処理機能はもともとHBaseでは強く求められませんが、運用中はできるだけデータベースの種類を減らしたい気持ちがありますから、HBaseでcross-row、cross-tableトランザクション処理機能をサポートする必要性がありました。すでにHBaseにおけるトランザクション処理のOSSが幾つか存在していますが、トランザクション処理要件、対応HBaseバージョン、導入の難易さ、社内ツールとの連携性などを検討して内製することになりました。設計中は主にPercolatorとhaeinsaを参考にしました。 スペック トランザクション処理は要件によって設計が異なります。私達の導入予定案件では、トランザクション規模は小さくて、WriteよりReadの方が明らかに多いです。そのため、スペックは以下のように定義しました。 インテグレーション方式は、導入と移行の便利さを考えてクライアントライブラリに決めました。使用者はプロジェクトにこのライブラリを導入するだけで済みます。HBase側の対応は必要ありません。 使い方は以下のような感じです。 分離レベル アプリケーション側でトランザクション処理をする場合に、性能に一番影響するのはHBaseにアクセスするときの通信コストです。高い分離レベルは優れた並列性を提供できますが、通信回数を増やせば性能は逆に落ちることがあります。 例えば、HBase cell versionを利用してMVCC(Multi Version Concurrency Control)で分離レベルSnapshot Isolationを実装してみると、データの取得は二段階になります。 まずは有効なデータバージョンを取得し、そして有効バージョンでデータを取得します。分離レベルSerializableの場合はロック情報とデータは同じ行に保存すると、アクセス時に一緒に取得できます。Snapshot IsolationよりHBaseアクセス回数が少ないです。そしてSnapshot Isolationの場合は、cellごとに有効バージョンを保存するカラムが必要です。テーブルのカラム数が倍になってしまうと（この場合の分離単位はcellです）ストレージとネットワーク通信に対して大きなデメリットがあります。分離レベルSerializableの場合はテーブルにロック情報を保存するカラムを一つだけ追加すればいいです。 Concurrency Control よりよい並列処理能力を提供するため、OCC(Optimistic Concurrency Control/楽観的並行性制御)を採用します。トランザクション処理の一時結果はコミット段階までHBaseに書かずメモリに保存します。ロックもコミット段階までかけないようにします。 例えば、同じresourceを使うトランザクション処理t1、t2があります。 t2(read only)がt1より開始時間が遅くなりますが、t2はt1コミット開始前に完了すると、両方とも成功です。PCC（Pessimistic Concurrency Control/悲観的並行性制御）の場合は、t2は失敗です。 t2がt1より開始時間が遅くなります。t2はt1コミット前にコミット完了した場合、t2は成功ですがt1は失敗です。PCCの場合はt2は失敗です。 コミット コミット段階は実際にHBaseデータを入れる段階です。Two-phase commitプロトコールを使用してトランザクション処理の原子性を保証します。トランザクション処理を４つの状態に分けます。 BEGIN: 最初の状態です。user logicを処理して、結果をメモリに保存します。 PREWRITE: コミットフェーズ１。ロックをかけます。処理結果をHBaseに保存します。 COMMITTED: コミットフェーズ2。PREWRITEでかけたロックを解除します。 ROLLBACK: PREWRITEは失敗したら、トランザクションロールバックを行います。 状態を保存するため、HBaseに二つデータモデルを追加します。 Row status column family アプリケーションで使うすべてのテーブルにこのColumn Familyを追加します。CAS APIのコンペア機能は一つのcellをチェックしますから、isLocked:tid:ts の形で一つのcellに保存します。 ロックを長くかけないように、他のプロセスがロックされた行にアクセス時、もしロック時間(tsからの時間)が長いならロックを解除することができます。 Transaction status table トランザクション状態を保存します。アプリケーションごとに一つだけが必要です。 フェーズ1 トランザクション状態はPREWRITEになっています。CAS APIを利用して、変更した行ごとにデータの更新と同時にロックをかけます。もしCAS操作が失敗した場合は、Conflict(更新するデータはすでにロックがかけされます)が起きてると見なされるのでロールバックを行います。 データ更新の擬似コード 全ての行が更新されたら、トランザクション状態をCOMMITTEDに変更します。 トランザクション状態変更の擬似コード フェーズ2 トランザクション状態はCOMMITTEDになっています。実行プロセスはすべてのrow lockを持っていますのでConflictが起きません。ロックはほかのプロセスから解除することが可能です。二度とロックを解除しないようにCAS APIを利用してロックされた行ごとにロックを解除します。 擬似コードはこうなります。 すべてのロックを解除したらトランザクション処理が終わります。HBaseに保存したトランザクション状態をFINISHEDなどに変更する必要性はありません。 ロールバック コミット中Conflictなどが発生したらすでに更新したデータの取り消しとロックの解除をしなければなりません。HBaseのCell Versionを利用してロールバック機能を実装しました。データをHBaseに入れるときにトランザクションごとでバージョンを付けます。ロールバック中は指定バージョンのデータを削除します。 ロールバック中でもClient Faultなどが起きるかもしれないため、複数のプロセスが同時にロールバックできるように設計しました。それでもロールバックをしようとする時に、他のプロセスがすでにロールバックをしたこともあります。ロールバック時点で行とトランザクションの状態確認が必要です。 プロセスは自分が処理しているトランザクションのロールバックをするときに、トランザクション状態をROLLBACKに変更してみて、成功したらすでに更新した行のロールバックをします。 トランザクション状態をPREWRITEからROLLBACKに変更するときの結果によって行為も違います。 行状態の変更が成功したら、ロックの解除とデータの削除を行います 行状態の変更が失敗したら、行のトランザクション状態を確認します トランザクション状態変更の擬似コード 行のロールバックの擬似コード newStatus、lastStatusともトランザクション状態テーブルに行ごとに保存しています。 トランザクション id トランザクション idについての要件は 一意に識別するための識別子です 更新したcellのバージョンとして使います 単調増加 (データを取る時にいつも最新のデータをとります) トランザクションid生成スピードはトランザクションの生成スピードを制約します (…)
↧
HBase Cross Row、Cross Tableトランザクション処理機能を実装してみました
↧
CMake を使ったクロスプラットフォーム開発環境
こんにちは、LINE で LINE GAME Clinet SDK の開発をしている やまぐち です。 この記事は LINE Advent Calendar2016 の 10 日目の記事です。 弊社でも iOS / Android / Unity 向けに LINE GAME Clinet SDK を提供しています。コードは共通の C++ を使っているのですが、複数のプラットフォーム向けにビルドを行う必要があってソースファイルの管理やビルド方法がバラバラで大変ですよね。そこでクロスプラットフォーム向けのビルドシステムなどを調査してCMake を使ってクロスプラットフォームビルド環境を作ることにしました。 CMake を採用した理由 巷ではクロスプラットフォームでビルドをするための色々なソリューションがあります。ざっと上げてみると CMake Ninja GYP Bazel などなど、他にも沢山あるかと思います。まず、前提として以下の要求を満たせるか、色々なソリューションを調査しました。 ソースコードの一元管理が出来る。 シェルなどからビルドが出来る。 C++ ビルドはもちろん、Java、Objective-C などもビルドが出来る。 これを元に色々とベンチマークを取りました。その結果 CMake を採用することになりました。今回 CMake を採用した理由ですが C、C++、Java、Objective-C など複数の言語のビルドが可能。 CMake は toolchain や custom target を使って柔軟にビルドが出来ます。 サードパーティのライブラリが CMake のビルドをサポートしていることが多いので、ビルド連携がしやすい。 CMakeLists.txt を自分のプロジェクトで読み込めば取り込むことが出来る！ Xcode や Visual Studio のプロジェクトファイルも吐き出せる。 IDE 環境が恋しくなってもこれで安心！ 昔からあるから情報が多そう。 といった感じです。最後はかなり個人的な憶測が入っていますね。では実際に CMake を使ってクロスプラットフォームビルド環境を構築していきましょう。 CMake を使ったビルド Toolchain ファイルの準備 CMake は標準で gcc、MSVC などに対応しています。標準的なコンパイラーでビルドするのであれば何も考えずにCMakeLists.txt を作れば良いのですが Android などは専用のコンパイラーなどが用意されているので CMake から利用出来るようにするために Toolchain ファイルを作ります。これは CMake に対してコンパイラーはこれを使いますよー的なファイルでこれさえ作ればどんなコンパイラー環境にも対応出来るという訳ですね。 では早速、準備をしてみましょう。まずは github に Toolchain を公開してくれている人がいますのでそちらを使わせてもらいましょう。iOS の Toolchain はここに、 Android の Toolchain はここにあります。そのままでも十分に使えるので、最初はそのまま使って良いと思います。実際に構築した環境では上記の Toolchain をベースに clang でビルド出来るようにしたり c++_static を使えるようにしたりと若干のカスタマイズを行っています。 CMakeLists.txt (…)
↧
↧
マイクロサービスのためのプロジェクト生成ツール Lazybones を使ってみた
こんにちは。LINE ゲームのプラットフォーム開発を担当している Kagaya です。6 日目の記事を担当した 川田さんと同様、今年の 4 月から新卒で入社して主に Java を使ったサーバサイド開発を担当しています。 こちらの記事は LINE Advent Calender 2016 の 11 日目の記事になります。 はじめに LINE のサービスの多くは Microservices Architecture と呼ばれるような構成になっています。このアーキテクチャそのものについては、過去の LINE Developers Blog でも こちらの記事 で扱ったり、Developer Day にて こちらの講演 を行ったりしています。様々なメリットが提唱されていますが、チーム開発の機能的な側面から言えば、巨大なシステムの各機能を疎結合にすることで、新しくチームにジョインしたメンバーでも開発をスピーディに行う事ができるのがメリットといえるでしょう。 LINE ゲームのプラットフォームも同様に Microservices 化されており、チームの Github Enterprise には多くのリポジトリが存在しています。さて突然ですが、我々のチームに配属されたあなたが新機能を開発するために新しくリポジトリを作りました。最初の一歩としてどのように開発を進めていくことを考えるでしょうか？Microservices の利点のひとつにコードベースの独立性があるとはいえ、まずはテンプレートのようなものからスタートするのが一般的だと思います。プロジェクト内のディレクトリ構成から、横断的に利用しているミドルウェアやチーム内でよく使われるビルドツールの設定など、多かれ少なかれ存在するであろう共通部分をテンプレート化するのはエンジニアにとっては常套手段です（DRY 原則という言葉もあります）。 例えば、我々のチームでは Spring Boot をよく利用しています。Spring が提供している Spring Initializr というサービスを皆さんご存知でしょうか？いくつかの設定項目を入力するだけで、Spring Boot Application の hello world を簡単に行うことができるサービスです。こういったツールのように、少しの設定でテンプレートからスケルトン生成を行うことができると、本質である新機能のコーディングに集中することができます。本記事では、私が所属するチームでも採用を検討している Groovy 製プロジェクト生成ツール Lazybones について紹介したいと思います。 プロジェクト生成ツール その前に、Java のプロジェクト生成ツールといえば忘れてはいけない Maven Archetype の話を少ししたいと思います。Maven は Java で広く使われているビルドツールで、弊社でも多くのサービスで現役です。その Maven を使ったプロジェクトのイニシャライザ、スケルトン生成に用いることができるプラグインが Maven Archetype です。利用方法について解説したページは多く存在しますのでここでは割愛しますが、mvn archetype:generate コマンドを入力後、対話形式・非対話形式で version や package 名のパラメタを指定をすることでスケルトンを生成できます。 一方で、Maven と並んで（後継として？）よく利用されているビルドツールに Gradle があります。我々のチームでも新規開発サービスにおいては Gradle への移行を開始しています。Maven Archetype は非常に便利ですが、Maven に特化したツールなので、Gradle を利用したプロジェクトを生成するにはやや相性が悪くなっています。よく云われるように、Gradle 公式では Maven における Maven Archetype に当たる機能は用意されていません。それは、Maven が XML ベースの「設定ファイル」によってビルドを行うのに対し、Gradle が Groovy を利用した「スクリプト」であるという設計思想の違いに依存していると思われますが、それでも一種の「初期化」は必要な工程です。さて、その初期化を行うには、いくつかの選択肢があります。 公式の gradle init (Gradle 1.9 から導入、前身である setupBuild (…)
↧
リアルタイム画風変換とその未来
こんにちは。LINE Fukuoka でデータ分析やその基盤作りをしている tkengo です。この記事は LINE Advent Calendar 2016 の 12 日目の記事です。 2016 年の 11 月下旬、LINE Fukuoka で 2 日間の社内ハッカソンが開催されました。その時にいくつかのチームが結成され、IoT や VR、機械学習など、それぞれのチームで挑戦的なプロダクトが作られ、大いに盛り上がりました。今日は、その時に私たちのチームが作ったディープニューラルネットワークを使った以下のようなリアルタイム画風変換アプリケーションのお話をしたいと思います。 ※ちょっとわかりにくいですが、下側のスマホのカメラに映っている映像に対してリアルタイムに画風変換処理を施し、それを上側のスマホで表示しています。 背景 2015 年の夏の終わり頃、ニューラルネットワークを使って画像の画風を変換するアルゴリズム A Neural Algorithm of Artistic Style が、 Gatys らドイツの研究者グループによって発表され、世界中で話題になりました。日本でも同時期に Chainer を使った実装 とその 解説記事 が出ましたので記憶にあたらしい方も多いのではないでしょうか。 ただ、Gatys らの提案したアルゴリズムでは、ニューラルネットワークへの入力として適当に生成したノイズ画像 (もしくはコンテンツ画像やスタイル画像) からはじめて、だんだんとコンテンツとスタイルが混ぜ合わさった画像に近づいていくようなアプローチです。イテレーション毎に毎回、誤差を逆伝搬させる計算をする必要があるため画像生成に時間がかかりすぎていました。その後、そのような問題を解決するために 2016 年になって非常に高速に画風変換を行うためのアルゴリズムが発表されていきました。 Texture Networks: Feed-forward Synthesis of Textures and Stylized Images Perceptual Losses for Real-Time Style Transfer and Super-Resolution これらは CPU のみを使っても数秒〜数十秒のオーダーで変換処理が完了するような高速さで、まさしくタイトルにもある通りリアルタイム性すら求めることができそうです (※学習にはもちろん時間がかかります。高速なのは学習済みモデルを使った変換処理です。) さらに、これらの変換を動画に適用してみようというアルゴリズムも登場しています。 Artistic style transfer for videos このように様々な画風変換のアルゴリズムが発表されており、画風変換の人気の高さがうかがえます。 さて、私たちはこのような画風変換をスマートフォンのカメラを通してリアルタイムで処理できると面白いのでは、と考えました。Prisma というアプリをご存知でしょうか？静止画に対して様々な画風変換のフィルタをかけることができるものですが、ちょうどそれのリアルタイム版と考えてもらって問題ないでしょう。ハッカソンでは、リアルタイム画風変換アプリケーションを作るために、前述した Johnson らによるアルゴリズム Perceptual Losses for Real-Time Style Transfer and Super-Resolution を使いました (※この中には画像の高解像度化の手法も含まれますが、そちらは関係ないのでこの記事中では扱いません)。アプリケーションとして一般に公開できるレベルまで到達することはできませんでしたが、いろいろな試行錯誤と工夫を繰り返してなんとか形にだけはなったので、その取り組みを紹介していきたいと思います。 リアルタイム画風変換 まずは Johnson らによる画風変換のアルゴリズムの簡単な紹介をしたいと思います。 モデル Johnson らの提案したモデルには、上図に示すような 2 つのネットワーク Image Transform Net と Loss Network (VGG-16) が存在します。 Image Transform Net は実際に入力画像にスタイルを適用して変換してくれるもので、複数の畳み込み層と Residual (…)
↧
YAPC::Hokkaido 2016 SAPPORO と Fukuoka Perl Workshop #27 の登壇報告
どうもこんにちわ! LINE LIVEを開発している@Yappoです。この記事はLINE Advent Calendar2016の13記事目です。 はじめに 今回は他の記事とは毛色を変えて Perl 成分濃いめでお届けします。 今更 Perl かと思われるかと思いますが、弊社でも幾つかのサービスを Perl で構築しており現在もサービス提供を行っています。 また、ご存知の方は少ないかと思いますが、日本のエンジニア界隈で一大ブーム巻き起こしている Engineer’s Advent Calendar ですが、もともとは2008年に日本の Perl コミュニティで開催された事が発端なんですよね。 今回の記事を読む事で、この Engineer’s Advent Calendar が Perl コミュニティから産まれた理由、そのエンジニア文化の背景などの一端に触れて頂けたら幸いです。 登壇の背景 基本的に筆者は LINE LIVE の開発をしていますが、過去の案件で社内向けの LINE BOT API Client を書いていた縁もあってMessaging API の Perl SDKの開発を担当しました。 この SDK は9/29の LINE DEVELOPER DAY 2016 で公開され、その時ちょうど良いタイミングで YAPC::Hokkaido でのトーク募集や Fukuoka.PM での登壇のお誘いを頂いたので、 Messaging API や付随するサービスを Perl から使う方法についてのトークを行うこととしました。 YAPC::Hokkaido 2016 SAPPORO まず最初に YAPC の解説をしますと、 YAPC とは Yet Another Perl Conference の略称です。当時、参加費用が少々高額な The Perl Conference というイベントが開催されておりましたが、有志が「もう少しリーズナブルで気軽に参加できる Conference を作ろう！」という主旨で新しい YAPC というイベントを立ち上げました。(なお国外では2016年からは The Perl Conference と名前を変えています) 日本では Shibuya Perl Mongers 有志の運営により2006年に最初の YAPC が開催され、現在では 一般社団法人 Japan Perl Association(以下JPAと記す) 主催で毎年開催されている Perl の Conference となっています。 今回は12月10日に、日本の YAPC では初の関東以外の開催地となる札幌にて YAPC::Hokkaido 2016 SAPPORO が開催されました。 筆者の応募したトークも無事に採用していただいたため「LINE BOT on (…)
↧
↧
Sparkと機械学習と時々MPI
はじめに こんにちは、LINEで機械学習エンジニアを担当している久保です。この記事はLINE Advent Calendar2016の14記事目です。 今回の記事は、機械学習の（勾配などの）基本的な知識を持ち、Sparkにおける機械学習に興味がある人向けの内容となっています。 Sparkは大規模なデータのための分散処理フレームワークとして人気があり、弊社でも機械学習関連の開発において利用しています。 弊社では機械学習の特徴量の元となるデータがHDFSに格納されているため、それらを容易に読み込むことができる親和性の高さと、分散処理のコードが容易に実装できる所がSparkを利用する上での大きな魅力となっています。 具体的な利用方法として、例えば機械学習エンジンに入力する特徴量を作成するためのETL（抽出、変換、ロード）処理に利用しています。 また、LINE STOREにおける着せ替えの商品ページの右枠にあるアイテムベースのレコメンドやLINEアプリ内でLINE NEWSを立ち上げた際にトップ画面に出てくる「FOR YOU」枠のためのユーザベースのレコメンドなどにおいて、Sparkの機械学習ライブラリであるMLlibを用いてモデルの学習を行っています。 しかし、機械学習の扱うモデルのパラメータが巨大であったり、オンライン学習やミニバッチ学習により短い時間で良いモデルを求めたいケースにおいて、Sparkの分散処理フレームワークだけで機械学習手法を実装することが難しくなります。本記事では、まずSparkの分散処理フレームワーク上で実装できる機械学習の実装パターンを取り上げます。そして、それらの実装パターンにおいて払わなければならないデータ転送のコストに触れ、Sparkによる機械学習において向いている手法と向いていない手法を解説します。また、向いていない手法を実現するという課題に対してLINEにおけるMPI（Message Passing Interface）を使った事例をご紹介したいと思います。なお、こちらに記載されている内容はSpark 1.6に基づいています。 Sparkの分散処理フレームワークにおける機械学習 Sparkの分散処理フレームワーク上で実装できる機械学習の実装パターンを以下のテーブルに示します。 また、それらの実装パターンがSparkの機械学習ライブラリであるMLlibに実装されている手法のどれに採用されているかも示します。 ちなみに、Sparkは複数のTaskをWorkerに発行して、その結果を受け取る一台のSpark Driver（以後、Driver）と、Workerの役割を果たし、一台で複数のTaskを処理する複数台のSpark Executor（以後、Executor）からなります。
↧
新語・固有表現に強い「mecab-ipadic-NEologd」の効果を調べてみた
LINE の Data Labs(データラボ)で自然言語処理に関連する技術に関わっている @overlast (佐藤 敏紀) です。この記事は、LINE Advent Calendar 2016 の 15 記事目です。 この記事をお読みの方には「LINE と自然言語処理って関係あるの？」と思われる方もいらっしゃる思います。 Data Labs ではデータ収集・解析基盤の開発や機械学習技術の適用だけでなく、自然言語処理に関する実用的な技術の開発・研究を、かなり真面目におこなっており、その成果によって弊社のお客様のお役に立つことは当然として、他社さまや研究者、学生さんにも広く貢献したいと考えております。 はじめに 今回は、私が作っている mecab-ipadic-NEologd とその効果について、このブログで一回も書いていなかったので書きます。 mecab-ipadic-NEologd は形態素解析エンジン MeCab と共に使う単語分かち書き辞書で、週2回以上更新更新され、新語・固有表現に強く、語彙数が多く、しかもオープンソース・ソフトウェアである という特徴があります。 この記事では、mecab-ipadic-NEologd の分書分類タスクにおける有効性を確認する実験をおこない、その結果として「安心して最新版の mecab-ipadic-NEologd を使って大丈夫」という結論を得たことについて書きました。 色々な方々が頑張って下さっているおかげで mecab-ipadic-NEologd は Kuromoji からも使える様になっており、川田さん(@hktechno)による 6 記事目、(Elasticsearch を検索エンジンとして利用する際のポイント)の記事に出てきた「Elasticsearch のすごいところは、大量のドキュメントの中から形態素解析や n-gram など自然言語的な解析を行った上で(略)」という部分にも関係してきます。 この記事は、自然言語処理が必要そうな仕事をなさっているエンジニアさんにオススメの記事ですので、最後まで読んで頂いたり、「新語や未知語が足りない問題」などで困っているお仲間にオススメして頂けると、とても嬉しいです。 例文:「彼女はペンパイナッポーアッポーペンと恋ダンスを踊った。」 形態素解析エンジン MeCab (メカブ) は日本語のテキストを解析する際に、「形態素」という普通の単語よりも少し細かい単位でそのテキストを区切ります。MeCab は形態素解析をする際に辞書を使っていて、IPADIC(アイピーエーディック) と UniDic(ユニディック) という名前の辞書が有名です。 まずは例文を MeCab + IPADIC で処理した結果を確認しましょう。私の環境ではこの様に出力されました。 「ペンパイナッポーアッポーペン」という曲名は「未知語(辞書に無い単語)」として処理されました。MeCab は未知語に読み仮名を勝手に付与しないので、簡単に未知語を見分けることができます。 ドラマのエンディングで新垣結衣さんらが披露したことで有名になったダンスの「恋ダンス」という通称は 恋 ダンス の様に、2つの IPADIC に採録されている名詞として分割されました。 助詞 :「は」「と」「を」 動詞 :「踊る」の連用形 助動詞 :「た」 などの名詞以外の形態素も得られました。 形態素解析時に固有名詞が分割されてしまう4つの理由 「ペンパイナッポーアッポーペン」や「恋ダンス」の様に、文字列からイメージできる実体が複数の人物間でほとんど同じであり、他の名詞と明確に区別可能な固有の呼び名になっている名詞を「固有名詞」と呼びます。国名、地名、建物名、店名、人名、グループ名、法人名、書籍名、曲名などは固有名詞になりやすいです。 MeCab + IPADIC によって固有名詞が複数の形態素に分割される理由は多々あるのですが、そのうち分かりやすい4つの理由を挙げます(詳しい解説は省略)。 理由1. IPADIC や UniDic は形態素解析のための辞書 理由2. IPADIC や UniDic は更新の頻度が低い(または更新停止状態) 理由3. 形態素解析と固有表現抽出は別の研究トピック 理由4. 未知語を検出するにはデータが必要 このような理由が今後も消えないことを前提として、固有名詞がバラバラになる問題を少しでも解決するためには、 形態素単位での単語分割にこだわらず、固有名詞を1単語として分割する 定期的に更新して、現実の状況を反映する よく使われる固有名詞にはあらかじめ対応する 未知語は見つかり次第対応する という方針で分かち書き処理を改善するための言語資源を作り、さらに、この方針が悪影響を与えない様にするため、 既存の形態素解析の結果が実用上正しい時は尊重する という状態を実現できれば良さそうだと考えました。 mecab-ipadic-NEologd を使いましょう mecab-ipadic-NEologd は形態素解析用の辞書ではなく「単語分かち書き」用の辞書です。 この辞書を使って分割した際の単語の粒度が形態素になるか分からないので、単語分かち書きと呼んでいます。 mecab-ipadic-NEologd には以下のような4つの特徴があります。 IPADIC では複数の形態素に分割されてしまう固有表現を採録 (…)
↧
セキュリティエンジニアからみたUnityのこと
この記事はLINE Advent Calendar 2016の16記事目です。 こんにちは、LINEエンジニアの愛甲健二です。所属は「セキュリティ室」の「Application Security Team」というところで、主にリリース前のGames/Appsの診断を行っている、いわゆる一般的なセキュリティエンジニアです。今日はUnityに関するセキュリティ視点の入門記事を書きたいと思います。 はじめに そもそも「Games/Appsのセキュリティ診断って具体的に何をするのか」という話ですが、基本的にはアプリの解析と、通信プロコトルの解析/診断をメインに行います。 アプリの解析にはいくつかのツールを使うのですが、まず.dexを分析するためにJava Decompilerを使います。有名なものにJD-GUIがあります。ただ、デコンパイルに失敗するメソッドがあったりするので、そのときはsmali（AndroidのJavaVM実装）を直接読みます（smali）。smaliはApktoolを使って.apkを展開するとファイルが作成されます。コード分析においてはJava、ARM、そしてIL（Intermediate Language）が読めればほぼ問題ないので、それぞれJD-GUI、IDA、JustDecompile辺りを使います。これらは後ほど改めて解説します。 またゲームサーバとのHTTPS通信も確認したいため商用のBurp Suiteを使います。MITMについてはこの記事では触れませんが、「[Unity/C#]WWW/HttpWebRequestにおける中間者攻撃の危険性を考慮した通信プログラムまとめ」という記事が対策も含め詳細に解説されています。あとは一般のメモリチートツール/自作ツールを使って簡単にcheckしたり、メモリをdumpして内容を確認する、また私はあまり使いませんが、Xposed、Frida、Cydia Substrateを使い、動的に動作を検証することもあります。 ゲームにおけるセキュリティリスクは大きく2つあり、ひとつは「悪意あるユーザーがゲームプレイを（大幅に）簡略化できるもの」もうひとつは「悪意あるユーザーが他ユーザーに被害を与えられるもの」です。 前者は、他プレイヤーに直接的には被害を与えないが、ゲームプレイを大幅に簡略化できるもので、例えば「アイテムやコインを無限に入手できる」「スタミナを一瞬で回復できる」「botによりゲームプレイを自動化し、プレイしなくても強くなれる」といったものが挙げられます。こちらは、アプリを解析されるといずれ実現される、いわゆる対策不可能問題ですが、最悪サーバ側で各ユーザーのプレイログをベースに異常検知（bot/cheat/abusing検知）を行えばアカウントを凍結できます。 後者は「他ユーザーの持つアイテムを自由に売ることができる」「PlayerIDを差し替えることで他ユーザーの認証を突破できる」「他ユーザーの個人情報を（ゲームプロトコルを通して）入手できる」といった例が挙げられます。ゲームの通信は大抵は独自に暗号化されているため、Black-boxによる診断だと、まずアプリの解析を行い、通信プロトコルを分析した上ではじめて調査ができます。当たり前ですが、こちらの方が脆弱性としてはCriticalです。 最近だとほとんどのゲームはUnityもしくはCocos2d-xで作られているため、これらGame Engineの仕組みを理解し、アプリ（ゲーム）を解析し、その上でサーバ側の脆弱性を調査するのがGame Security診断の業務となります。今回はその中でもUnityに関係する部分に限定して解説したいと思います。 Unity Unityは有名な「Game Engine」のひとつで、最近はAndroid/iOS向けの、いわゆるスマートフォンゲームによく利用されています。マルチプラットフォームに対応しており、Android/iOSはもちろん、その他のスマートフォン、PC、各種ゲーム機用の実行ファイルを出力でき、様々な開発シーンで使われているGame Engineです。今回はAndroid/iOSに限定した（どちらかというとメインはAndroidで、iOSは補足的に説明する感じの）話になりますが、Unityについてセキュリティ視点で書きたいと思います。 またセキュリティ視点なのでプログラミングやゲームの作り方についてはまったく触れません。内容はUnityの仕組みに関する初歩的なもので、主にMono(IL)、IL2CPP辺りに興味がある方を対象としています。 Game Securityはわりとマイナーな技術分野ですが、少しでも興味を持ってもらえたら幸いです。 Mono Monoは.NET Framework互換環境を提供するオープンソースソフトウェアのひとつです。Unityはこれを用いてマルチプラットフォームを実現しています（mono-project）。Unityアプリは、IL（Intermediate Language）と呼ばれる中間言語を実行ファイル内に持ち、実行時に機械語へ変換、実行します。ILにはCIL（Common Intermediate Language）、MSIL（Microsoft Intermediate Language）がありますが、この辺はあまり本筋と関係ないため説明は省きます（Common Language Infrastructure (CLI) Partitions I to VI）。 ゲーム開発者が書いたコードは中間言語であるILとして実行ファイル内に保持されているため、まずはそれを確認します。 UnityのAsset Storeから、Survival ShooterというUnityを学ぶためのチュートリアルゲーム「Survival Shooter tutorial」をUnityへImportします。これをAndroid向けにビルドしてapkファイルを作成します。apkファイルを展開し、\assets\bin\Data\Managed以下を見ると、Assembly-CSharp.dllファイルがあります（iOSだとNightmares.app\Data\Managed以下にあります）。この中にゲームのコードが入っています。 ゲーム本体となる*.dllは.NETのDLLファイルであるため、.NET用のdecompilerでILに戻せます。decompilerには有名なもので、ILSpy、JustDecompileがあります。ILを編集するためにReflexilも必要です。JustDecompileならば、起動後Plugins -> Plugins Managerを選択し、Assembly EditorをダウンロードすればPluginとして組み込まれます。 Assembly-CSharp.dllをJustDecompileで開き、ReflexilでPlayerHealthのTakeDamageメソッドの先頭Instructionをretに変更します。 .method public hidebysig instance void TakeDamage ( int32 amount ) cil managed { IL_0000: ldarg.0 # 変更: ldarg.0 -> ret IL_0001: ldc.i4.1 IL_0002: stfld bool CompleteProject.PlayerHealth::damaged IL_0007: ldarg.0 IL_0008: dup これによりTakeDamageメソッドは何も実行せずにcall元に処理を返します。TakeDamageはPlayerのダメージを計算、反映する処理なので、変更したAssembly-CSharp.dllをapkの中に戻してre-pack/re-signすれば、Playerがダメージを受けない状態でゲームを続けられます。 IL2CPP IL2CPPはその名の通り、ILをCPPに変換するツール（オプション）です。UnityのBuild SettingsからPlayer Settings -> Other Settings -> Configuration -> Scripting Backendで設定できます。IL2CPPに関する詳細はAN INTRODUCTION TO IL2CPP INTERNALSを参照してください。 IL2CPPでビルドしていた場合*.dllはなく、代わりにlibil2cpp.so内にゲームコードが存在します（iOSの場合はMach-O実行ファイルに含まれます）。この場合プロセッサに対応した機械語になるため、解析には有料の逆アセンブラであるIDAがよく使われます。 IL2CPPを使った場合、メソッド名、参照文字列は\assets\bin\Data\Managed\Metadata\global-metadata.dat内に置かれており、libil2cpp.soから動的に読み込まれます。そのためIDAでsoファイルを開いただけではメソッド名、参照文字列は見えません。よって構造体、オフセットをベースにこれらを復元する（名前付け）するIDA Script（unity_metadata_loader）を使います（Demo）。unity_metadata_loaderはオープンソースなので、詳細が知りたい方はコードを読んでみてください。作者の資料も公開されています（Mobile Game Security）。 Androidの場合はlibil2cpp.soを、iOSの場合はMach-O実行ファイルをIDAで開いて上記Scriptを実行します。 さきほどと同様にSurvival Shooter (…)
↧
LINE BOT AWARDS API協賛企業のご紹介
今回の記事では、ただ今絶賛エントリー募集中のLINE BOT AWARDSに、API協賛企業として参加いただいている各企業の協賛内容をご紹介します。 中には日本マイクロソフト社のMicrosoft Azureなど、本来有償のものをLINE BOT AWARDSにエントリーいただいている方に特別に無償提供しているものもあります。 是非この機会にエントリーください。様々なAPIを上手く活用した、斬新なbotが数多く生まれることを期待しています！ 各社のAPI協賛の内容(順不同) hachidori株式会社 同社のプログラミングレスチャットbot作成プラットフォーム「hachidori」を無償でご利用いただけます。お手続きは以下の通りです。 アカウントを作成します。 botの作成をクリックし、LINEを選択します。 その中で、ディレクションに沿って必要情報を入れていただくと、サーバーレスで、botの作成が完了します。 日本マイクロソフト株式会社 Microsoft Azureを無償でご利用いただけます。 ご利用の詳細な手順は下記をご参照ください。 【コード認証】 Azure Passのアカウントを作成します。 居住国とLINE BOT AWARDS事務局から発行されたPromo Codeを入力し、Submitをクリックします。 Sign Inをクリックし、マイクロソフトアカウント(個人用でも法人用でも使用可能)に入ります(マイクロソフトアカウントをお持ちでない場合は、新規作成をクリックしてアカウントを作成してからご利用ください)。 確認ページに飛びますので、記載事項に間違いがないことを確認し、Submitをクリックしてください。 Azure上で提供しているサービス内容を確認後、Activateをクリックします。 【Azure Pass利用開始方法】 Azure Pass Activateのための必要事項を記入し、利用規約を確認の上Sign Upをクリックします(数分かかることがありますので、そのまましばらくお待ちください)。 Sigh Upが完了しましたら、利用開始になります。 【諸注意】 先着30名までとなります。 2017年2月4日までにActivateしてください(それ以降は無効となります)。 100ドル/月までを無料でご利用いただけます(超過分は料金が発生致します)。 株式会社IDCフロンティア IDCFクラウドを開発期間中に無償でご利用になれます(上限10,000円)。 IDCFクラウドのアカウントを作成します。 クラウドコンソールにログインして、画面右上のアカウント設定＞支払い方法を開きます。 お支払い方法の登録後、支払い方法下のクーポンコードをクリックし、LINE BOT AWARDS事務局から配布させていただくクーポン番号を入力してください(お支払い方法の登録を行ったからといって、料金が発生するわけではありません。ご安心ください)。 入力完了後、すぐにご利用開始になります。 【諸注意】 先着100名までとなります。 株式会社ゼンリンデータコム 「いつもNAVI API」は、サービス目的に応じた地図機能を、自由なデザインレイアウトで組み込むための開発ツールです。 「住所検索」や「郵便番号検索」、「施設検索」などの検索機能や、「徒歩ルート」「自動車ルート」などのルート検索機能もあり、地図に関する豊富な機能を取り揃えています。 お手続きは以下のとおりです。 いつもNAVI開発キットAPIプランから仮登録します。 仮登録後、案内に従い本登録へ進みます。 ご使用が開始できます。 【諸注意】 月間5,000PVまでという利用制限を設けさせていただきます。 HOYAサービス株式会社 VoiceText Web APIは、高性能な音声合成VoiceTextが利用可能なWeb APIです。 こちらのWeb APIでは、「喜」「怒」「悲」の3感情を表現できる「感情音声合成」をご使用いただけます。 お手続きは以下のとおりです。 VoiceText Web APIのアカウントを作成します。 無料利用登録をクリックし、指定の項目を入れ手続きを進めると、APIキーが発行され、ご利用いただけます。 a. 詳細のマニュアルはこちらをご確認ください。 【諸注意】 HIKARI、HARUKA、TAKERU、SANTA、BEARのみご利用可能です。 (SHOWは感情音声合成を使用できません) 希望者には、LINE BOT AWARDS終了までの期間、有料版をご利用可能です。 cloud.voice@hoya.com宛てに、「登録ユーザー名・APIキー・自身のメールアドレス」を記載の上ご連絡ください。 株式会社ヴァル研究所 以下の2種類のAPIをご使用いただけます。 駅すぱあとWebサービス 「駅すぱあとWebサービス」は、「駅すぱあと」経路検索の機能を、 Webサイトやモバイルアプリなどに組み込み可能なクラウド型APIです。 「駅情報」や「路線情報」などは無料のフリープランで商用利用可能です。 駅すぱあと路線図 「駅すぱあと路線図」は日本全国の駅を含む鉄道網を1枚で表示するWebベースの路線図です。 路線や駅に不動産やアルバイト情報、駅周辺の店舗情報などを自由に表示することが可能です。 株式会社NTTドコモ 好みのチャットbotを自由に作成することのできるサービス、「Repl- AI」をご活用いただけます。 GUIエディタ機能が充実していて、ユーザーの情報や発話内容に応じて対話の流れを変えるように設計することもエディタ上で実現可能で、コーディングをする必要はありません。 また、当初30日間は無料でご利用いただけます。 PayPal Pte. Ltd. Tokyo Branch PayPalのテスト環境であるSandboxの提供やSandboxへ接続するすべてのAPIをご活用いただけます。 お手続きは以下のとおりです。 1. PayPalDeveloperアカウントをお持ちでない方は、アカウント作成から行ってください。 2. PayPal Developerアカウントをお持ちの方は、Quitaの記事などWeb上にある記事をご参照のもと、API、Paypal Sandboxの利用環境を整え、ご利用ください。 【備考】 (…)
↧
↧
LINE Haskellブートキャンプ
こんにちは、LINEでフロントエンド開発を担当しているJunです。 2016年10月24日～28日の５日間、「LINE Haskellブートキャンプ」というプログラムがLINEの渋谷オフィスにて開催されました。今回の記事では、同プログラムに参加した感想を書きたいと思います。 Haskellとは Haskellは、柔軟性、合成可能性(composability)、安全性を維持しつつ、高性能のソフトウェアの作成を可能にする現代的なアプリケーションプログラミング言語です。ここ最近、Facebookやスタンダードチャータードなど複数の企業でHaskellを導入して商用利用の可能性を検証した例が増えており、数多くの言語・ライブラリがHaskellの方法論を借用して業界から注目を集めています。 LINEでも勉強会を立ち上げてHaskellを学習したり、社内サービスをHaskellで開発したりするなど、Haskellへの関心が高まっています。こうした中、5日間にわたって開かれた「LINE Haskellブートキャンプ」は、Haskellに興味のあるエンジニア同士が集まってHaskellに入門してみるプログラムでした。同ブートキャンプは、Haskellに対する奥深い学術的考察というよりは、誰もがHaskellに興味を持って使い始められるように、初心者レベルから学習することを目標にしました。進行役は、Haskellを使って社内サービスを開発した経験があるHanさんが担当してくれました。 なぜ、Haskellなのか Haskellで高性能のプログラムを安全かつシンプルに作成する例を紹介します。 import Data.List (isPrefixOf) appendIfNeeded xs ys = if xs `isPrefixOf` ys then ys else xs ++ ys 上記のappendIfNeeded関数の定義にはデータ型を一切明示していません。でも、Haskellの型推論のおかげで、関数の引数であるxsとysは比較できるリストであることが保証されます。この関数にリストではない値を入力した場合、またはリストの引数が比較できないデータ型である場合は、コンパイラはエラーを出します。Haskellの型推論は、コードをシンプルに維持しつつ、間違ったコードが実行されるリスクを減らします。 Haskellが保証する安全性は、値の型だけにとどまるものではありません。以下のような型を持つ関数があると仮定してみましょう。 toString :: Integer -> String 上記のtoString関数は、整数を引数として受け取り、文字列を返す一般的な関数で、どの言語でも作成できます。しかしHaskellは、この関数について、「同じ整数が引数として提供されれば、いつ、どこでこの関数が実行されても同じ文字列を返す」ということを保証します。つまり、Haskellの関数は、同じ入力値に対して常に同じ出力値を返すことが保証されます。一般の言語では、ある関数を呼び出したときにどんなことが起きるかは、コードを確認しない限り分かりません。ある関数を呼び出すことで、意図せずにファイルシステムにある特定のファイルをサーバに送信したり、大陸間弾道ミサイルを発射したりすることもあり得ます。しかしHaskellでは、関数の型を見るだけでも、そうした期待外れの動作が発生しないことを確信できます。 readFile :: FilePath -> IO ByteString 一方、readFileは、特定のファイルパスを受け取り、そのファイルの内容を読み込む関数です。この関数はファイルシステムにアクセスする必要があり、ファイルシステムはいつでも変化できます。Haskellはこの場合、IOという型で関数をアクションにすることができます。アクションは、実世界とコミュニケーションすることができ、ファイルの入出力やネットワーク通信などの有意味な副作用を作り出すことができます。大事なのは、IO型によって指定されたアクションだけがそのような副作用を作り出せるということです。Haskellでは、副作用に対する例外処理のためにアクション以外のコードを確認する必要がありません。こうした副作用の分離は、コードの構造を改善するだけでなく、メンテナンスにかかる手間も減らす効果があります。 このように、Haskellは型レベルで副作用を管理することで参照透過性(referential transparency)を確保できる言語です。どの関数がどの型の値を引数として受け取って返すのか、時間と空間に関係なく常に同じ値を返すのか、副作用を発生させることができるのか、などをコンパイル時に把握できます。その結果、同時性と並列性が実現しやすくなります。同時性と並列性は、現代のプログラミングにおいて重要なテーマであり、かつ難しいテーマでもあります。ほとんどの言語では、プログラマがより注意を払うことでそのような難しさを克服します。それに対し、Haskellコンパイラは十分な情報を持っているため、独自で同時性を管理できます。 f x + g y 上記は、fという関数をxに適用した結果と、gという関数をyに適用した結果を合計する式です。Haskellの「+」はIOアクションではないので、コンパイラは型を明示しなくてもfとgもアクションではないことが分かります。これは、f xとg yが時間と空間に関係なく同じ値を返すという意味です。そのため、f xとg yが同時に実行されても、他のCPUコアで実行されても結果には影響を与えません。したがって、コンパイラに並列化に関する簡単なヒントを与えるだけでも並列計算を実行するプログラムを作ることができます。 f x `par` g y `pseq` f x + g y 上記のコードにおいて、par関数はf xとg yを同時に実行させ、pseq関数は左側の実行が完了してから右側の計算を実行させます。ここで適切なコンパイル引数または実行引数を指定すれば、f xとg yが自動的に並列化します。同時性・並列性の実現のためにプロセスやスレッド、スレッドプールなどを使いながら奮闘する必要はありません。 以上のように、Haskellはシンプルなコードで安全性、参照透過性、同時性などを確保できる合理的かつ革新的な設計となっており、性能や合成可能性、コミュニティ、エコシステムなど、様々な魅力を持っています。 Haskellブートキャンプ ブートキャンプは、月曜日から金曜日までの5日間、午後に2時間ずつ毎日行われました。相当な時間を投入しないといけないプログラムでしたが、たくさんの開発者が集まってくれました。会場がいっぱいになるほどの人数で、Haskellに対するLINEエンジニアたちの熱い関心をうかがうことができました。 同ブートキャンプは、まずHanさんのスライドを見ながらHaskellの基本概念と規則を学習し、その後みんなでライブコーディングを実習する形で行われました。Haskellの文法はシンプルですが、慣れていない初心者には少し難しいかも知れません。実際にHaskellを学ぼうとする人の多くが、この段階でよく諦めてしまいます。LINE Haskellブートキャンプは、Haskellに入門する開発者たちがHaskellのコーディングに慣れることに重点を置きました。 興味深いことに、Haskellブートキャンプに参加した開発者たちの主な担当分野は、クライアント、サーバ、フロントエンドなど多岐に渡っていました。Haskellは、「なんとしても成功を避けよう(Avoid success at all cost)」という非公式のモットーを掲げ、型破りで実験的なプログラミング言語の発展を図ってきました。こうしたHaskellの発展は、他の言語にも良い刺激剤となりました。Javaのラムダとジェネリクス、ScalaのOptionやFuture型、SwiftのOptional chaining、JavaScriptのPromiseやasync/awaitなど、多数の言語の機能がHaskellの影響を受けて誕生しました。これはつまり、Haskellを学習すれば、普段使っている言語への理解も深まることを意味します。Hanさんは、Haskellの概念を説明する際に、それに対応する他の言語の機能も合わせて紹介してくれました。そのおかげで、Haskellの理解を促進することができ、プログラミング分野におけるHaskellの価値を実感することもできました。 ブートキャンプでよかった点は、果てしなく難しく感じられるかもしれないHaskellを、実用の観点から説明しようとしたことでした。例えば、Haskellというと通常、ラムダ計算、圏論、型クラス、モナドといった、聞くだけで難しくて怖いイメージの概念が思い浮かびます。しかしHanさんは、柔軟性、合成可能性、安全性といった実用面にフォーカスしてHaskellを説明しました。当たり前のことですが、Haskellを使うために圏論の博士号などが必要なわけではありません。Haskellを学習する方法も他のプログラミング言語のそれと大して変わりません。まず触れるレベルになったら、いろいろ作ってみながら少しずつ難しい概念を習得していく。LINE Haskellブートキャンプはその第一歩として重要な役割をしたと思います。 LINE Haskellブートキャンプは、通常のHaskell勉強会とは若干異なるカリキュラムを採用しました。一日目は、Haskellコミュニティで一般的に使われるプロジェクト管理ツールであるStack、パッケージおよびドキュメントのリポジトリとして使われるStackageについての説明がありました。さらに、String型の非効率を解決するTextやByteString、Haskellのメタプログラミングを可能にする拡張のTemplate Haskell、Webアプリケーション・インターフェースであるWAIなど、今すぐHaskellを使って何か面白いものを作るために必要なツールを紹介しました。Haskell勉強会は下手すると学術的になりがちですが、LINE Haskellブートキャンプは多様な分野の開発者に役立つ実用的な内容で構成されていたことが印象的でした。 もちろん、5日間ずっとコードとライブラリの話ばかりしていたわけではありません。ブートキャンプの重要な目的の一つは、Haskellへの興味と意欲を引き出すことでした。そのため、HanさんはHaskellを使うべき理由について様々な例を交えて説明しました。LINEでは、数多くのエンジニアたちが、それよりさらに多くの装置を用いて、それより遥かに多くのユーザーが利用するサービスを開発しています。このような環境で一番重要なことの一つは、サービスの信頼性(reliability)です。他の多数の言語が信頼性を確保するために様々なツールと規約を開発者に強制しているのに対し、Haskellはプログラミング言語レベルでより安全なプログラムを保証します。信頼性が何より重要な状況なら、Haskellはいい選択肢になるはずです。また、Haskellは、プログラミング自体に興味と情熱を持っている人々から大きな注目を浴びています。これはつまり、Haskellを使用すれば、強いモチベーションを持っている優秀なエンジニアたちと一緒に働ける機会が増えることを意味します。LINEのように優秀な開発者の募集に積極的な会社であるほど、Haskellの価値はさらに高く評価されるはずです。 最終日の「モナド怪談」セッションもとても興味深い内容でした。モナドはHaskellを難しく感じさせ、Haskellを学ぼうとする人々を挫折させる概念の一つです。実際に、モナドという概念は圏論からきたもので、これを完璧に理解するには高度な学術的知識が求められます。Hanさんはこれに対し、「モナドを理解することでHaskellプログラマになろうとするのは、『楽器とは何か』を理解することで楽器の演奏者になろうとするのと同じ」という表現を引用しました。楽器の演奏者になるために楽器の哲学的な意味を理解する必要がないように、Haskellを実用ツールとして使用するためにモナドの学問的な意味まで理解する必要はありません。結局、圏論とモナドという単語から感じられる怖さ自体が、Haskellの学習で陥りやすい落とし穴なのです。「モナド怪談」セッションでは、そのような落とし穴の存在をHaskell学習者に事前に知らせ、難しい単語のせいでHaskellへの興味を失ってはいけないと強調しました。 おわりに Haskellに興味のある方は、LINEでHaskellを使用していることや勉強会が開催されたことに驚いたのではないでしょうか。私もかなり前からHaskellに興味を持っていましたが、それを会社で使う機会があるとは思いませんでした。LINE Haskellブートキャンプは、LINEがIT企業として技術とツールの重要性を忘れない会社であり、向上心に満ちた仲間たちと一緒に働ける職場であることを改めて実感できるきっかけとなりました。個人的にもわくわくする楽しいプログラムでした。 同ブートキャンプで得られた最も大きな成果は、Haskellが商用利用に必要な実用性を十分に備えていることを確認できたことでした。Haskellが学界発の言語であることは確かですが、すでに世界有数の企業がHaskellを導入して成功を収めています。これは、Haskellが学界だけでなく、産業界でも有用なツールであることを裏付ける証拠であると、Hanさんは強調しました。ブートキャンプでもHaskellの様々な実用的なツールが紹介されましたが、その中にはソフトウェアトランザクションメモリなど、サービスに実際に導入してもいいと思えるものがたくさんありました。時間の都合上、各ツールに関する詳しい説明は聞けませんでしたが、Haskellの実用性を体験することができました。 今回のブートキャンプをはじめとする様々な取り組みが今後実を結び、次回はさらに面白いニュースを皆さんにお伝えできればと思います。例えば、LINEでのソフトウェア開発にHaskellをより本格的に導入し、それによって開発されたソフトウェアを技術面から詳しく解説できるようになれば何よりです。最後に、ブートキャンプ最終日の「モナド怪談」セッションで使われたスライドを以下に掲載しておきます。
↧
2016年LINE Security Bug Bounty Programの結果について
常時運営化について こんにちは。LINEでセキュリティに関する業務を担当しているMJです。 今回の記事では、2016年の「LINE Security Bug Bounty Program」を振り返り、皆さんにご紹介していきたいと思います。このプログラムは、サービスに潜在的に存在する脆弱性を外部のエンジニアの方々からご報告を頂き、我々が迅速に修正していくことで、皆様により安全なサービスを提供することを目的としています。 まず、2015年に8月24日～9月23日の期間限定で試験的に実施し、そして、(1)プログラム内容の改善 (2)リスクの継続的な管理を目指して、プログラムの利用規約、報告フォーム、報告内容の判定基準、さらに常時運営を前提とした運営体制等のあらゆる側面の改善を準備し、2016年6月2日より「LINE Security Bug Bounty Program」として新たに運営をすることとなりました。 LINE Security Bug Bountyのトップページ: https://bugbounty.linecorp.com/ 脆弱性報告フォーム: https://bugbounty.linecorp.com/apply/ プログラムのFAQ: https://bugbounty.linecorp.com/ja/faq/ 日付/脆弱性別の受付状況 LINE Security Bug Bounty報告フォームから受付した状況は以下のとおりです。 常時運営の開始日2016年6月2日から12月31日までの約7ヶ月間で、97件の報告を受付いたしました。以下の【図1】は、日別(週別)の受付件数、受付脆弱性名の割合をグラフで表現したものです。 国別アクセス 今回受付けた97件のうち、日本国内からは15件、海外からは82件でした。以下【図2】は、常時運営期間、WEBサイトにアクセスした国別アクセスの割合ですが、日本のみならず海外からも高い関心があったことがわかりました。 審査について 受付した内容は、1次審査、2次審査に分けて行われました。審査については、前回の記事でも紹介しましたが、 1次審査、2次審査を通ったものが脆弱性として認定され、報奨金の対象になります。認定されると、Hall of fameに報告者の名前、認定された脆弱性のカテゴリなどが公開されます。 審査ステータスは以下のとおりです。 1st ACCEPT：脆弱性報告の提出資料として審査可能と判断した状態です。 1st REJECT：脆弱性報告の提出資料として審査不能と判断した状態です。 2nd ACCEPT：資料の内容を精査して脆弱性として認定された状態です。 2nd REJECT：資料の内容を精査して脆弱性として認定されなかった状態です。 Completed：報奨金の支払いまで完了した状態です。 審査結果 今回のプログラムでは、XSS、CSRFなど合計13件が脆弱性として認定されました。 2016年の常時運営プログラムを通じて発生した報奨金の総額は、27,000 USDでした。 審査結果については、Hall of fameページから確認することができます。 Hall of fameの更新状況はこちらのページでアナウンスを行っています。 審査の結果、利用規約上プログラムの対象ではなかったため、正式には認定できないものがあり、 その中でもLINEにとって有益な情報であった報告については、特別な取り扱いとしてSpecial Contributorsという枠を設け、 2016年には、8人の方を認定させていただきました。 おわりに 皆様の高い関心とたくさんの有益な報告のおかげで、LINE Security Bug Bounty Programを通じてLINEは多くの改善を達成することができました。 報告いただいた脆弱性はすべて修正されており、ユーザーの皆様はLINEサービスをより安全に利用することができます。 LINE Security Bug Bounty ProgramがLINEのセキュリティリスクを減らす取り組みの一環のプログラムとして、さらに良質なものへと拡張/発展できるように努力したいと思います。 現在、LINEが提供するサービスの数も増加し、さらにグローバルに拡大している状況であるためプログラムの対象の拡大については特に優先的課題として検討を続けております。 LINE Security Bug Bounty Programサイトでは常時脆弱性報告を受け付けていますので、今後も皆様のご協力とご参加をお待ちしております。
↧
LINEのデベロッパー向け情報をまとめたポータルサイト「LINE Engineering」公開とBlog更新について
こんにちは、日本のLINE Engineer Blogを担当している櫛井です。 LINEのデベロッパー向け情報をまとめたポータルサイト「LINE Engineering」公開と、今後のBlog更新についてお知らせいたします。 技術的な情報などをお知らせしている LINEの公式Twitterアカウント@LINE_DEVにて先行してお知らせしていましたが、LINEのデベロッパー向け情報をまとめたポータルサイト「LINE Engineering」を公開しました。 LINE Engineering 日英韓3言語に対応しており、LINEの開発文化や提供しているオープンソース、各ドキュメントや採用情報などへのリンクを掲載しています。新しい情報やコンテンツも更新していきますので是非チェックしてください。 Blogについて、これまでは「LINE Engineers’ Blog」にて更新をしていましたが、LINE Engineeringの公開にあわせてBlogも引っ越しをすることとなりました。今後はhttps://engineering.linecorp.com/ja/blogをご覧ください。 ※LINE Engineers’ Blog (http://developers.linecorp.com/blog/ja/ ) は今後更新いたしません サイトの更新情報、LINE Engineerが関わる登壇情報やスポンサー情報などは@LINE_DEVにて随時お知らせしていますので、是非フォローしてくださいね！
↧