LINE Engineering Blog official account
こんにちは、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では強く求められませんが、運用中はできるだ
LINE Engineer
こんにちは、LINE でスタンプ・着せかえショップのバックエンド開発をしている川田 (@hktechno) です。 この記事は、LINE Advent Calendar 2016 の 6 日目の記事です。 今年の4月に、Java も Elasticsearch もまともに知らなかった新卒エンジニアが Elasticsearch クラスタの管理を突然任されて苦労した話をしようと思います。 Elasticsearch とは Elasticsearch は、Elastic 社が開発している検索・分析エンジンおよびそのストレージを担うソフトウェアです。簡単に言えば、検索に特化したクエリを投げることができるデータベースのようなものです。No-SQL 型の DB といっても良いと思います。 Elasticsearch のすごいところは、大量のドキュメントの中から形態素解析や n-gram など自然言語的な解析を行った上で、素早く検索クエリを処理でき、かつノードを増やすことで簡単にスケールアウトすることができることです。最近では、Elasticsearch は様々なログの収集・分析にも使われるように
本日2015年6月30日、LINE Login PlatformをLINEではない他のサービスでも利用できるように公開しました。 今回の記事では、公開されたLINE Login Platformについて紹介しようと思います。 技術的な内容が掲載されているLINE developersサイトも公開いたしましたので、どのような機能を利用することができるのか、ぜひご覧になってください。 LINE Login Platformとは? LINE Login Platformとは、皆さんが開発したスマートフォンアプリやウェブアプリケーションの中で、LINEアカウントを使用したログイン機能を組み込むためのプラットフォームです。すでに多くのスマートフォンアプリやウェブアプリケーションが、LINE Login Platformを使ってログイン機能を利用しています。ここでは、例としてPopcorn BuzzとLINE STOREそれぞれでどのようにログイン機能が利用されているのか紹介してみます。 Popcorn Buzz: スマートフォンアプリの場合 Popcorn Buzzは、同時に最大200人と無料で
LINE Dev
こんにちは、LINE+開発室のパク・サンジン(SJ)です。今回は、文字数をカウントする方法についてお話したいと思います。LINEサービスではプロフィール名やグループ名、ひとことなど様々なところで文字数をカウントしていますが、画面で文字が短すぎたり長すぎないようにし、ストレージ容量を正しく割り当てるためには、文字数を正確にカウントすることがとても重要です。特に、LINEは全世界で使っているサービスなだけに他言語の文字数も正確にカウントできなければなりません。 ある日、BTS(Bug Track System)のプロフィール名にemojiを入力すると1字が2字で表示されるといった、文字数が正確にカウントされないという課題が登録されました。emojiとは、日本で使い始めたもので、今ではUnicode標準に含まれ世界的に広く使われるようになった絵文字セットのことです。最初は、単純にSurrogateカウントエラーの問題だと思い分析し始めました。Surrogateとは、UTF-16エンコードを16ビット以上に拡張させる文字セットのことですが、emojiにはSurrogateで表現する文字がある
LINEとマイクロサービス LINEのアプリは、トークをはじめとして、電話、ショップ、公式アカウントなど、多数のサービスで構成されていますが、これらのサービスはモノリシックな単一のシステムとして開発されているわけではありません。それぞれ独立したシステムとして開発・運用され、お互いにAPIを介してコミュニケーションする、いわゆるSOAやマイクロサービスと呼ばれるアーキテクチャになっています。 本エントリでは、大規模なマイクロサービス環境において、システムのトレーサビリティを向上させるためのLINEバックエンドの取り組みを紹介します。 マイクロサービスの課題 最近よく耳にするマイクロサービスですが、その利点は、システムを扱いやすい小さな部分にわけ、疎結合にすることで、全体としては巨大なシステムであってもそれぞれのサービスは独立してスピーディーに発展できる点にあると思います。 一方、リクエストが複数のサービスにまたがって処理されるため、リクエストの処理全体を追跡する能力（トレーサビリティ）が低下するというリスクが生じます。例えばあるリクエストのレイテンシの悪化を調査したいというような場合、そ
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graphなどの中心となるロジックを担当するCore Messaging Application、その他に機能別に様々なApplicationに分かれて構成されています。特に、その中でコアロジックを担当するCore
こんにちは開発チームの崔珉秀と申します。 今回はnginxというウェブサーバーについて話をさせて頂きます。nginxは最近数年の間けっこう人気が高くなっています。特によく使われているApacheやLighttpdなどのウェブサーバーと性能の面で比較することがよくありまして、優れた性能で単純なstaticファイルを転送するウェブサーバーからCGIサーバー、reverse proxyサーバーなどの様々なウェブリクエスト処理に関わる分野で導入されています。今日はnginxの性能の比較よりもサーバーの開発者(nginx module)もしくはサーバーの運営者としてのnginxにある仕組の中で一つを紹介したいと存じます。 サーバーの開発や運営をする場合ロジックや設定などの変更により配布の後、サーバーを再起動することがあります。その再起動の時にウェブサービスとしてリクエストの処理を続けながら、変更の内容を反映するための手段がいくつかあります。他のウェブサーバーも普通設定の変更の場合は“優雅な再起動(graceful restart)”でウェブリクエストの処理を中断せずに変更
お世話になっております、開発チームの池上です。 最近ちょっとした検索機能にSolrを導入しました。Solrは検索エンジンのミドルウェアでご存知の方も多いと思います。大規模な構成による導入実績が豊富でWeb上にもたくさんの事例がありますが、今回は慎ましい構成の事例を紹介させて頂こうと思います。 使用しているSolrのバージョンは2012年1月時点で最新の3.5.0です。なお、検索エンジンやSolrに関する基礎的な情報につきましては、有用な解説がすでに多数存在していますので割愛させて頂きます。 今回はつぎの前提条件と要件を意識して構築しました。 前提条件 サーバは極力少なめで ミッションクリティカルな機能ではない データ量はそれほど多くない 要件 更新はある程度頻繁 遅くとも数分以内にはインデックスに更新を反映させたい 一般的なWeb検索のように「いい感じに見つける」よりは「（入力されたキーワードを）正確に見つける」 設計のポイント サーバ構成 最低限サーバ障害は考慮して2台。更新の反映は若干の遅延が許容されていましたので、検索性能を安定させやすいMaster/Slave構成としま
こんにちは検索サービス開発４チームの崔珉秀と申します。インフラやシステムとの連携や統計のバックエンドを担当しております。 モバイルのウェブ環境はPCのウェブ使用環境とは色々な違いが有ります。ネットワークの速度だけではなくバッテリーの効率を考えた仕組みなど、PCに比べリソースが十分ではないためモバイルブラウザの動作が異なっていることも有ります。今回はモバイルのウェブApplicationにおけるSSL関係の性能に関する工夫の内容をQ&A形式で解説していきます。 Q. 何が問題でしたか？ A. モバイルクライアント(iPhone, Android)のアプリケーションからのHTTPリクエストの応答時間に遅延の問題が有ります。最初はweb access logからのslow response(１秒以上)のHTTPリクエストが結構ありました。そのHTTPリクエストをprotocol別(http/https)でまとめてみると遅い応答のほとんどがhttps(SSL)のリクエストになっていることがわかりました。 Q. 明確にhttps(SSL)のHTTPリクエストで何が遅いですか？ A. サー
