RSS

Archive for the “バックエンド開発” category

内部データパイプラインへのKafka Streamsの適用

by LINE Engineer on 2016.8.19

Kafka Streamsのご紹介 こんにちは。LINEでサーバ開発エンジニアとして働いているYuto Kawamuraです。主にHBase、KafkaといったLINEの中核的なストレージを開発・運営しています。 昨年下期からは、IMF(Internal Message FlowまたはFund)と呼ばれる新規プロジェクトも担当しています。このIMFプロジェクトの目的は大きく2つあります。 内部システム間のevent deliveryを統一された方法で行うデータパイプラインの開発 LINEサーバシステムにおけるバックグラウンド処理を担当するコンポーネントの一つであるtalk-dispatcherの置き換え この2つの目的は互いに関連性がないようにみえますが、これらの目的を達成するために、Apache Kafkaとストリームプロセッシング技術を適用することを考えています。Apache Kafkaは、LinkedInによって開発され、使われてきた大容量の分散メッセージングシステムです。ユニークな機能を多数提供していますが、一番重要な特徴は次のとおりです。 ディスクベースの永続化を提供すると同時に、ページキャッシュを活用してインメモリに引けをとらない高いスループットを実現しています。 複数のconsumerが一つのtopic(queueのような概念)から複数回メッセージを取得できます。このようなやり方が可能なのは、クライアントがそのqueueからどこまでデータを取得したか、その位置を知らせてくれる「offset」を管理しているためです。 Kafkaエンジニアリングの基本やIMFプロジェクトのコンセプトアイデアなど、面白いテーマはたくさんありますが、今回はストリームプロセッシングの実装方法にフォーカスしてご紹介します。

Spark、Mesos、Zeppelin、HDFSを活用した大容量セキュリティデータの解析

by LINE Engineer on 2015.6.3

LINE Plusでゲームセキュリティ開発を担当しているWJ、KHです。 莫大なユーザーがモバイルからアクセスするLINEゲームにおいて、データの迅速な解析と対応はそう容易なものではありません。LINEゲームへのアクセスと海外ユーザーの大幅な増加に伴い、様々なアビューズ(不正とされる操作を通じて不当な利益を得る行為)行為が次々と観察されています。アビューズ行為は、正常にゲームを利用する善意のユーザーに迷惑を掛けることはもとより、ゲームサービスそのものにも直接的な影響を及ぼします。ゲームの安定性を守り善意のユーザーを保護するためには、アビューズ行為に迅速に対処することがとても大事です。 アビューズ行為が探知されたら、異なった形式のログを関連付けて解析しその問題の原因を洗い出して修正する必要がありますが、このとき一番の障壁は、大容量のログデータの速やかな処理でした。LINEで扱う各種データ量の増加により、従来の伝統的なビッグデータ処理方式では現象が発生してから事象を確認するまで数十分、数時間が掛かってしまいます。また、データ形式(RDB、NoSQL、File、API)や大容量サービスのためのData Shardingのような技術導入などの理由から、すべてのデータを連携することも容易ではありませんでした。何よりも、人気ゲームの場合は流入されるデータ自体が非常に多いのです。いろんな観点から迅速なデータの処理を可能にする多彩なオープンソースを組合せ、その可能性をチェックしてみました。結果として、作業の分配とリソースの活用にはApache MesosとApache Sparkを活用し、データのビジュアライズ(可視化)にはApache Zeppelinを採用することが希望のデータ処理要件に最も近いことが分かり、適切な構成を試みることになりました。

文字数をカウントする7つの方法

by LINE Engineer on 2015.3.19

こんにちは、LINE+開発室のパク・サンジン(SJ)です。 今回は、文字数をカウントする方法についてお話したいと思います。LINEサービスではプロフィール名やグループ名、ひとことなど様々なところで文字数をカウントしていますが、画面で文字が短すぎたり長すぎないようにし、ストレージ容量を正しく割り当てるためには、文字数を正確にカウントすることがとても重要です。特に、LINEは全世界で使っているサービスなだけに他言語の文字数も正確にカウントできなければなりません。 ある日、BTS(Bug Track System)のプロフィール名にemojiを入力すると1字が2字で表示されるといった、文字数が正確にカウントされないという課題が登録されました。emojiとは、日本で使い始めたもので、今ではUnicode標準に含まれ世界的に広く使われるようになった絵文字セットのことです。最初は、単純にSurrogateカウントエラーの問題だと思い分析し始めました。Surrogateとは、UTF-16エンコードを16ビット以上に拡張させる文字セットのことですが、emojiにはSurrogateで表現する文字があるからです。しかしよく見ると、実際にはSurrogateとは関係のない2文字が入力されていることが確認できました。ということは、「emojiの後ろに共通的に追加されるcharacterがあるのでは」と思い、そのルールを探し出して例外処理をしようと考えていました。が、さらに他の課題が登録されてきました。 「タイ文字が正確にカウントできません。」 調査してみると、タイ文字だけでなくアラビア文字、インド文字でも似たような現象が発生していました。 タイは、LINEユーザーの多い重要な国のひとつです。人口2位のインドも重要な対象国ですし、アラブ地域もイランをはじめLINEユーザーの多い重要国が多いため、この問題を根本的に解決する必要がありました。最初に発見したことは、タイ文字(ภาษาไทย)、アラビア文字(العربية)、デーヴァナーガリー文字(देवनागरी、ヒンディー語)の共通点が組合せ型の文字だということです。こうやって組合せ型文字のUnicode標準などについて勉強しながら気づいたことは、文字数をカウントする簡単なことさえグローバルサービスになると思ったより簡単ではない、ということでした。

LINEのマイクロサービス環境における分散トレーシング

by yono on 2014.9.25

LINEとマイクロサービス LINEのアプリは、トークをはじめとして、電話、ショップ、公式アカウントなど、多数のサービスで構成されていますが、これらのサービスはモノリシックな単一のシステムとして開発されているわけではありません。それぞれ独立したシステムとして開発・運用され、お互いにAPIを介してコミュニケーションする、いわゆるSOAやマイクロサービスと呼ばれるアーキテクチャになっています。 本エントリでは、大規模なマイクロサービス環境において、システムのトレーサビリティを向上させるためのLINEバックエンドの取り組みを紹介します。

FluentdとNorikraを使ったLINE BusinessConnectエラー検知&通知の仕組み

by Yoichiro on 2014.8.6

LINE技術戦略室のYoichiroです。今回は、徐々に数が増えてきたLINE BusinessConnectのエラー検知とその通知の仕組みについて紹介してみたいと思います。

LINE BusinessConnectの技術話

by Yoichiro on 2014.5.23

LINE技術戦略室のYoichiroです。今回の記事では、先日発表させていただきましたLINE BusinessConnectの技術的な話を少ししてみようと思います。 LINE BusinessConnectとは? まずは、LINE BusinessConnectとは何かを説明しましょう。簡単に言うと「プログラムで自動応答可能な公式アカウントを作れます」というものです。

急増するLINEインフラの課題と対応

by LINE Engineer on 2014.5.8

急増するLINEインフラの課題と対応 こんにちは。今回はITサービスセンターより、インフラ運営の観点から急増するLINEインフラの課題と対応について記させていただきます。 はじめに 先日開催したLINE Developer Conference(インフラ編)には大勢の方にいらしていただきました。カンファレンスでは、LINEサービスが始まってから約2年の間に我々はどういった方法でインフラ運営を行い、またどんなことに悩んできたのかを、システム、データベース、ネットワークの観点からそれぞれ発表させていただきました。