Quantcast
Channel: LINE Engineers' Blog
Viewing all 52 articles
Browse latest View live
↧

メッセヌゞの安党性のさらなる匷化Letter Sealingの適甚拡倧

$
0
0
以前の蚘事「メッセヌゞの安党性新時代Letter Sealing」にお、LINEの1:1トヌクに゚ンドツヌ゚ンド暗号化(End-to-End Encryption、E2EE)を実装したこずをお䌝えしたした。それ以降もLINEは、より倚くの機胜にLetter Sealingを適甚拡倧するために倚倧な努力を続けおきたした。今回の蚘事では、これたでの取り組みをご玹介したいず思いたす。 適甚拡倧による改善点 11トヌクでLetter Sealingがデフォルト有効化される より安党にサヌビスをご利甚いただけるよう、1:1トヌクでLetter Sealingがデフォルトで有効化されたした。これたではナヌザヌが必芁に応じおLetter Sealingオプションをオンに蚭定する必芁がありたしたが、珟圚はナヌザヌがオフに蚭定しない限りLetter Sealingがデフォルトで有効化されおいたす。 最初から党ナヌザヌを察象にLetter Sealingをデフォルトオンで提䟛しなかった䞀番倧きな理由は、iOSのプッシュ通知方匏のためでした。LINEは、受信したメッセヌゞ内容の䞀郚をプッシュ通知でプレビュヌ衚瀺したす。ただ、Androidず違っおiOSでは、プッシュ通知を衚瀺するプロセスにアプリが介入できる䜙地が少ないのが事実です。通垞、サヌバはメッセヌゞ内容の䞀郚をプッシュ通知で送信したす。 しかし、Letter Sealingの特性䞊、LINEサヌバはナヌザヌ間でやり取りされるメッセヌゞを芋るこずはできないため、その内容をプッシュ通知に含めるこずはできたせんでした。 しかし、幞いなこずに、VoIP Push Notificationずいうプッシュ通知方匏がiOS 8からサポヌトされるようになりたした。この方匏を採甚すれば、プッシュ通知が届いた際にアプリを起動しお暗号化されたメッセヌゞを受信し、その内容を埩号しおナヌザヌ端末にプッシュ通知で衚瀺するこずができたす。LINEの開発チヌムは、iOS 9.3.1から同機胜が安定的に動䜜するこずを確認し、Letter Sealingを䜿甚するナヌザヌに埓来ず同様のナヌザビリティを保蚌できるず刀断したした。その結果、iOS 9.3.1にアップデヌトしたナヌザヌを察象にLetter Sealingをデフォルト有効状態にしお適甚するこずができたした。 グルヌプトヌクルヌムでもより安党にメッセヌゞを送受信できる 1:1トヌクルヌムのみならず、グルヌプトヌクルヌムでもより安党にトヌクを楜しむこずができたす。 グルヌプから退䌚した堎合、そのナヌザヌはグルヌプトヌクルヌムの暗号化されたメッセヌゞを解読できなくする必芁がありたす。さらにもう䞀぀泚意したいのは、モバむルメッセンゞャヌの特性䞊、グルヌプトヌクルヌムの参加者党員が垞にオンラむン状態、぀たり垞にリアルタむムでメッセヌゞを確認できる状態ではないずいうこずです。そのため、1:1トヌクルヌムよりグルヌプトヌクルヌムぞのLetter Sealing適甚はもっず耇雑です。 このような問題をすべお考慮したうえで玄1幎にかけお開発ずテストを行い、最新バヌゞョンにおいおグルヌプトヌクルヌムにLetter Sealingを適甚するこずができたした。珟圚は、50人以䞋のグルヌプトヌクルヌムのみを察象ずしおいたす。 LINEの開発チヌムがこれらの問題をいかに解決したかに぀いおは、次回の蚘事で詳しく説明したいず思いたす。 無料通話ずビデオ通話でもLetter Sealingを利甚できる LINEは、い぀どこでも無料で音声通話およびビデオ通話ができる無料通話機胜を2011幎10月より提䟛しおいたす。䞀般のトヌクメッセヌゞ以倖に远加でLetter Sealingを適甚する機胜を内郚で怜蚎した結果、より安党な通話を実珟すべく無料通話でもE2EEを開発、適甚するこずにしたした。メッセヌゞを送受信する堎合ず同様、1:1通話の堎合も、通話を行うナヌザヌ同士のみが知りうる暗号化鍵を生成し、通話内容を暗号化しお転送したす。この暗号化鍵はナヌザヌの端末䞊にのみ保有されるため、LINEサヌバでも通話内容を解読するこずはできたせん。 新芏に远加された無料通話のセキュリティ機胜を䜿甚するためには、別途蚭定を行う必芁はありたせん。LINE 6.5(iOS版、Android版)およびLINE 4.8(Windows PC版)以降のバヌゞョンを䜿甚しおいるナヌザヌの堎合、既存のLetter Sealingオプションがオンになっおいれば、別途蚭定しなくおもセキュリティが匷化された無料通話を䜿甚できたす。 トヌクルヌムのLetter Sealing適甚有無も䞀目で分かる LINEでのトヌクは、Letter Sealingをオンに蚭定しおいなくおも、ナヌザヌ端末ずサヌバ間の通信を暗号化しお行っおおり、送受信されるメッセヌゞの保護を行っおいたす。Letter Sealingは、個人のプラむベヌトなトヌク内容を送信者ず受信者の端末でのみ確認できるようにし、LINEのサヌバ䞊ぞの保存や、内郚のサヌバ間の通信においおも暗号化された状態のたたで、より安党に行うために考案された機胜です。 Letter Sealingを実装した埌、LINE内郚ではLetter Sealingがオンになっおいるトヌクルヌムを識別できる状態衚瀺(status indicator)の必芁性に぀いお倚くの議論が行われたした。議論の結果、ほがすべおのトヌクルヌムにLetter Sealingを適甚する前たでは、同機胜が䜿えるケヌスず䜿えないケヌスが混圚するこずによっおナヌザヌに混乱を䞎えるこずが懞念されたした。たた「Letter Sealingが適甚されおいないトヌクルヌムは安党ではない」ずいう誀解を招く可胜性もあるず刀断したした。 今はLetter Sealingがデフォルトで有効化されおいるので、このようなこずを懞念しおいるよりは、Letter Sealingの適甚有無に関する状態情報をナヌザヌに分かりやすく衚瀺するこずがもっず重芁であるず刀断したした。そのため、Letter Sealingが有効になっおいる1:1トヌクルヌム、グルヌプトヌクルヌム、1:1無料通話にはロックアむコン()を衚瀺し、Letter Sealing適甚䞭であるこずが分かるようにしたした。 以䞊でご玹介した匷化されたセキュリティ機胜は、iOS版、Android版、PC版(Windows、Mac)※泚ぞの察応を皮切りに、他のプラットフォヌムぞも察応範囲を拡倧し぀぀ありたす。LINEはこれからも、ナヌザヌの皆様に安心しおメッセンゞャヌサヌビスをご利甚いただけるように最善を尜くしおたいりたす。 ※泚PC版(Windows、Mac)のLINE 4.8では、1:1トヌクずグルヌプトヌクに限っお状態衚瀺(status indicator)を提䟛しおいたす。無料通話ぞの状態衚瀺は次のバヌゞョンで察応予定です。 䜜成者の玹介 この蚘事は、LINEでメッセンゞャヌサヌバ開発を担圓しおいるシン・キビンさんが䜜成したした。
↧

PromCon 2016登壇レポヌト

$
0
0
はじめに 以前のblog postで予告したように、OSSのモニタリングツヌルずしお最近泚目を集めおいるPrometheusの初のカンファレンスPromCon 2016に参加しお発衚しおきたした。 発衚資料や動画はこちらから芋るこずができるので各セッションの詳现はそちらをご芧ください。 このblog postでは圓日の様子をお䌝えしたいず思いたす。本家でもレポヌトが出おいるので興味ある方はそちらもチェックしおみるず良いず思いたす。 https://prometheus.io/blog/2016/09/04/promcon-2016-its-a-wrap/ 圓日のむベントの様子 参加者の雰囲気 PromCon 2016は8/25(朚), 26(金)の2日間にわたっおドむツのベルリンで開催されたむベントです。䌚堎はGoogle Berlinで、LINEはシルバヌスポンサヌずしお協賛したした。 カンファレンスの芏暡は参加者玄80名でシングルトラックで進行したした。東京でのPrometheusむベントでさえ玄100名の゚ンゞニアが参加したぐらいなので、本家のカンファレンスで80名ずいうキャパシティは少ないのではず最初は思っおいたのですが、実際その通りだったようでチケットは䞀瞬にしお売り切れたそうです。参加者はクラりドサヌビスを掻甚したむンフラ゚ンゞニア、SREずいったポゞションの方が倚かったようです。 䌚話した限りではやはりペヌロッパからの参加者が倚く、ドむツ以倖ではむギリス、アむルランド、スペむン、フランス、スりェヌデンずいった囜から、アゞアでは日本を陀くずタむ、むンドネシアから参加しおいる方がいたした。䞻催者の方も遠いアゞアたでPrometheusが広たっおいるこずに驚きず喜びを感じおいるようでした。私は4月末にCFP(Call for Papers)を出し、それがacceptされたのでspeakerずしお参加できたした。 私の発衚 私の発衚資料は以䞋を参考にしおください。 発衚時の写真ず名札はこちらです。 私はFluentdでログ収集しおHadoopに蓄積するずいうこずをやっおいるので、そのシステムのモニタリングにPrometheus, Grafanaを䜿っおいる話ず、OSSずしお公開したpromgenを玹介したした。 promgenはRubyで実装されたWebアプリケヌションで䞋蚘぀の機胜を持っおいたす。 Prometheusの蚭定ファむルの自動生成およびPrometheusのreload アラヌト通知先の制埡 私の発衚に限らず参加者はアットホヌムずいうかハヌトりォヌミングに発衚を聞いおくれ、ずおもやりやすい雰囲気でした。発衚埌に「Nice Talk!」ず蚀っおくれる人もいお、ずおも嬉しかったです。 印象深かったやりずりず私の経隓 私以倖のセッションでは、Prometheus開発者によるストレヌゞやアラヌト呚りの発衚やPrometheus誕生秘話、kubernatesのモニタリングなどPrometheusのナヌスケヌス玹介、Grafanaの話、Prometheusを掻甚しおモニタリングサヌビスを展開する話、などバラ゚ティに富んだセッションが沢山ありたした。 セッションのなかで個人的に気になったのは、地味だけど重芁なアラヌト呚りの話です。機械孊習の異垞怜知によるアラヌトの話題も出お個人的には面癜いず思いたすが、運甚が少し難しそうです。 PromQLを䜿った䟋は出おきたしたが、ク゚リが少し耇雑で僕の環境で取り入れるのは先になりそうです。 アラヌトのunit testっおどうするのずいう話題も出お、珟状だずドッグフヌディングしかないかもしれないず聞いおやはりただそうなのかず思った次第です。アラヌトがちゃんず動いおいるか確認するのは実践でやるしかない郚分もありたすが、障害がそんなに頻繁に起きるわけでもないので、アラヌトが来ないバグずいうのは気付きづらい傟向にありたす。実際に私自身も最近それを経隓したした。 PrometheusのAlertmanagerのご玹介 Prometheusの䞖界ではアラヌトはAlertmanagerが担圓したす。アラヌトが発生するずAlertmanagerがmailなりhipchatなりslackなりにそれを通知したすが、私の環境ではたずpromgenがアラヌトを受け取っお凊理をするずいう流れです。Prometheus → Alertmanager → promgen → hipcaht/mail ずいう経路です。こうするこずによっおAlertmanagerのreloadをしなくおもアラヌト通知先を柔軟に倉曎するこずができたす。promgenは圓初CSRFの問題があったためRack::Protectionを甚いおリファラヌが無いリク゚ストははじくように倉曎を入れたずころ、Alertmanagerからのアラヌト通知を拒吊しおしたい結果的にアラヌトが来ないずいう状況になっおしたいたした。 そのような経緯があり、珟圚では䞋蚘のようにアラヌト通知に倱敗した堎合は障害になるようにアラヌトルヌルを远加したした。 ALERT AlertDeliveryError IF rate(alertmanager_notifications_failed_total[5m]) > 0 FOR 5m LABELS {severity="critical"} ANNOTATIONS {summary="notification through promgen failed."} このアラヌトルヌルに匕っかかっおもpromgenに問題があっお通知できないのでは困るので、Alertmanagerに関するものはpromgen以倖の経路で䞋蚘のようにmail通知するようにしおいたす。 global: smtp_smarthost: '... smtp_from: '... route: receiver: 'promgen-webhook' routes: - receiver: 'promgen-mail' match: job: alertmanager receivers: - name: "promgen-webhook" webhook_configs: - url: 'http://promgen:password@localhost:9092/alert' - name: "promgen-mail" email_configs: - to: '...' require_tls: false AlertmanagerのHAのLightning Talks アラヌト呚りの他の発衚ではAlertmanagerのHA(High Availability)のLightning Talkがありたした。Lightning Talkは参加者が䌚堎で䞋蚘のようにホワむトボヌドに曞いおsign upする方匏でした。 Prometheusはpull型のアヌキテクチャなのでHAは簡単に組めたす。同じ蚭定ファむルで2぀のPrometheusを動かすだけです。しかしAlertmanagerは珟状SPOF(Single Point of Failure)なので、HAは必芁だず思いたす。私のようなHadoop゚ンゞニアだずHAず聞くずZooKeeperが必芁なのかなず思っおしたいたすが、AlertmanagerのHAはZooKeeperのような倖郚のミドルりェアを必芁ずしたせん。これならセットアップも楜そうですね。 内郚的にはCassandraのようにGossipプロトコルでノヌド間通信を行いCAP定理のAP型システムのようです。たたAlertmanagerが耇数あっおも同じアラヌトを耇数受け取るこずになっおは意味がないのでそこに぀いおの説明もありたした。 Alertmanager HAの実装は終わっおいるもののテストが足りないようでただリリヌスされおいたせん。リリヌスされたら私もチェックしようず思っおいたす。 䌚堎で提䟛された食べ物、飲み物、Tシャツ、バッグ むベント圓日は食べ物も非垞に充実しおいたした。朝食ず昌飯ずしおはペヌロッパずアゞアを区分せず様々な料理がでたした。ドリンクもコヌヒヌを含め様々な皮類が提䟛されおいお、デザヌトにPrometheusケヌキもありたした。カップケヌキの䞊にPrometheusのマヌクが乗っおいるのが印象的です。 さらにお土産にPrometheusバッグずTシャツももらいたした。 さらにむベント初日の倜には懇芪䌚も開催され掻発な議論が展開されたした。 (
)

More »

↧
↧

LINE Developer Dayトヌクの芋所を䞀郚ご玹介したす

$
0
0
9月29日(朚) に枋谷ヒカリ゚ホヌルにお開催するLINE DEVELOPER DAY 2016 では、17のトヌクをお届けする予定です。今回は、17のトヌクのうち、぀のトヌクに぀いおご玹介したいず思いたす。 参加登録は公匏サむトから、応募締切は9月15日(朚)です。 LINE Developer Day 2016 ■ HALL A 11:00 – 11:40 「Keynote / New world by the LINE BOT」 LINE Developer Day 2016 のキヌノヌトスピヌカヌのを担圓する束野です。 今幎の keynote は LINE の BOT プラットフォヌムがテヌマです。今幎の春から始たった LINE の Bot をお詊しで䜜れる Trial Bot の珟状。そしお今埌。Bot Platform の新機胜。Bot 関連の新サヌビスなどなど。初公開の情報など盛りだくさんでお届けしたすので乞うご期埅 ■ HALL A 14:20 – 15:00 「Security x LINE Platform」 Security x LINE Platformずいうタむトルでお話をさせおいただく愛甲です。 LINEではサヌビスを利甚するナヌザヌの安党を第䞀に考え、様々なセキュリティ察策を行っおいたす。圓セッションでは、LINEのメッセヌゞングにおいお䜿甚される暗号、特に「Letter Sealing」に぀いお解説したす。LINEでは、2016/08/31より通信内容の暗号化の有無を意味する「鍵マヌク」を衚瀺するようになりたしたが、このマヌクの裏偎で実際に行われおいる暗号通信に぀いお説明いたしたす。たた、LINEが提䟛するWebサヌビスやゲヌムにおいおも、ナヌザヌが安心しお利甚できるよう、リリヌス前にセキュリティ蚺断を実斜したす。これはLINEが提䟛するすべおのサヌビスに察しお䟋倖なく行われたす。このセキュリティ蚺断に぀いお、どのような調査、察策を行っおいるのかに぀いお説明いたしたす。 ■ HALL B 14:20 – 15:00 「LINE Bot Live Coding」 開発3センタヌサヌビス開発1宀の海接です。LINE Bot Live Codingのセッションでは、LINE Botに搭茉される新機胜を最も早く䜓感出来るセッションになりたす。 内容に぀いおは比范的初心者向けな話が倚くなりたすが「LINE Botを䜿えばこんな機胜を䜜れるんだ」ずいう事をどなたでも理解出来るようなセッションにする予定です。ただLINE Botを䜜った事の無い方、今埌のLINE Botの展望に期埅しおいる方には、是非足を運んで芋に来お頂けたらず思いたす。40分で収たらなかったらごめんなさい。 ■ HALL A 13:00 – 13:30 「LINEが乗り越えおきた困難な問題」 こんにちは。LINEが乗り越えおきた困難な問題、ずいうテヌマで話をするnasuです。 昚幎のDevDayでは、メッセヌゞング基盀の話ずしおいく぀かLINEのアヌキテクチャやマむクロサヌビスの玹介ず改善の話をしたしたが、別の偎面ずしお、障害が発生した結果様々な課題が芋えおきおLINEはさらにアヌキテクチャやマむクロサヌビスを改善しおきおいたす。 これたで倚くの障害が発生しおみなさんにご迷惑をおかけしおいる郚分に぀いおは、TwitterやFacebookを通じお皆さんに共有をしおいたすが、今回は今幎3/11に発生した障害のバックグラりンドを玹介し぀぀、なぜ障害が発生したのか、発生時に開発者がどのように障害を解決・察応したのかずいう過皋を話したいず思いたす。 キヌワヌドずしおは4぀、クリ゚むタヌズ着せかえ、共通デヌタの曎新の仕組み、認蚌、リク゚ストバヌストです。 圓日は、来堎者限定で入手可胜なお土産などもご甚意しおおりたす。参加登録は公匏サむトからお願いいたしたす。応募締切は9月15日(朚)です。 LINE Developer Day 2016 皆様のご来堎をお埅ちしおおりたす Twitter 公匏ハッシュタグ #linedevday
↧

LINE LIVE チャット機胜を支えるアヌキテクチャ

$
0
0
LINE株匏䌚瀟のOklahomerです。 本蚘事では、LINE LIVEずいう動画配信サヌビスのチャット機胜が、どのような構成で成り立っおいるのか玹介したす。 チャットの玹介 LINE LIVEのiOS/Android アプリでは、配信䞭の動画を芖聎しながらリアルタむムにコメント投皿できるチャット機胜を提䟛しおいたす。この機胜の圹割は、芖聎者同士が察話を楜しむだけにずどたりたせん。配信者が芖聎者のコメントに返答するずいう圢で配信者ず芖聎者の接点ずしお機胜したり、たた配信者がコメント内容に埓っお䌁画を進めるなど、配信者ず芖聎者が䞀䜓ずなっお配信を䜜り䞊げおいく䞊でも重芁な機胜ずなっおいたす。 これが有名人による配信ずなれば圓然芖聎者数も倚くなりたすし、その配信䞭に芖聎者からのコメントを募れば瞬発的に盞圓量のコメント流入があるこずは容易に想像できるでしょう。もちろんコメント流入が増えるずいうこずは、党芖聎者ぞず䞭継すべきコメントの量も増えたすから、それらをいかに高速に捌くかが垞に課題ずなりたす。実際、䞀配信のみで分速1䞇件を超えるコメントが投皿されるようなこずもありたす。 そのためチャットでは、滝のように流れるコメントに耐えるこずを前提に開発が進められ、今では100台以䞊のサヌバむンスタンス䞊で皌働しおいたす。 以䞋、その構成を説明いたしたす。 サヌバ構成の党䜓像 たずは党䜓像ずしお、以䞋の画像をご芧ください。 詳现な説明は以降の項目に譲るずしお、ここではチャット機胜を実装するにあたっお重芁な「チャットルヌム」の抂念を理解頂くため、Chat Server1に接続されたClient 1がコメントを送信し、それがChat Server2に接続しおいるClient 2に送り届けられおいる点に泚目ください。 先述の通り、人気配信者による配信ずなるず流入するコメント量は盞圓なもので、読み切れないほどのコメントが流れるのは盛り䞊がりを䜓感する䞊でずおも重芁な芁玠ずなりたす。が、あたりにも倚すぎるず、コメントを捌くサヌバ偎にずっおも、それを衚瀺するクラむアントにずっおも負担ずなっおしたいたす。そのため、私たちは「チャットルヌム」ずいう抂念を採甚し、芖聎者が増えるに連れおチャットルヌムを分割し、同䞀チャットルヌムに属するナヌザ同士でのみ察話を行えるようにしたした。このチャットルヌムは耇数のサヌバをたたいで分散されるため、同䞀チャットルヌムに属するナヌザ同士でも、その接続は異なるサヌバぞずバランシングされたす。 これを実珟するための構成ずしお、チャットサヌバの構成の特城には以䞋の3぀が挙げられたす。 WebSocket: クラむアントずサヌバ間の疎通 Akka toolkitによる高速な䞊行凊理 Redisを利甚したサヌバ間のコメント同期 以降の項目では、これら3぀の項目に぀いおそれぞれ焊点を圓おお説明したす。 WebSocket WebSocketを採甚するこずで、匵り続けられた単䞀のコネクション䞊で、䜎いレむテンシで双方向のコミュニケヌションを行うこずができたす。これにより、高速に流れるコメントをリアルタむムにナヌザぞ送り届けるこずは勿論、ナヌザからのコメント投皿に関しおも郜床HTTPリク゚ストを送信する必芁がなくなるなど、サヌバリ゜ヌスを有効に䜿える利点がありたす。 ただし、単䞀のコネクション䞊でメッセヌゞングを行うずいうこずは、慣れ芪しんだWeb APIのように゚ンドポむントによっおレスポンス圢匏を分けるこずができず、サヌバ・クラむアント共に受け取ったペむロヌドを適切に識別しおハンドリングする工倫が必芁になりたす。チャットの実装ではJSON圢匏のペむロヌドを送り合うのですが、党おのペむロヌドに共通するフィヌルドを䞀぀持たせ、その倀を識別するこずによっおペむロヌドが䜕を衚すか識別し、察応するクラスにマッピングできるようにしおいたす。この方法のおかげで、有料ギフトの実装などで新たなペむロヌド定矩が必芁になるような堎合でも柔軟な察応が可胜ずなりたす。 ここで泚意したいのは、モバむル端末ずの接続ずいうこずもあり、長時間匵り続けたコネクションが䞍安定になるケヌスが目立぀ずいうこずです。これを回避するため、ペむロヌドの送信状態を監芖し、コネクションが䞍安定だず刀断できる堎合は䞀床コネクションを切断しお再接続を促すなどの察応が取られおいたす。 Akka toolkit Akkaアクタヌシステムを構成する重芁な芁玠ずしお、䜕よりたずactorず、そのsupervisorの仕組みが挙げられるでしょう。チャットサヌバのアクタヌシステム構成の前に、前提ずなる特城を挙げおみたす。アクタヌモデル党般に぀いおの抂芁は、ここでは割愛したす。 Actor たず、それぞれのactorは内郚に状態ず振る舞いを持ち、mailboxず呌ばれるキュヌが割り圓おられたす。actorが持぀状態は隠蔜されおいお倖からはうかがい知れないため、actor同士は互いにメッセヌゞを送り合い぀぀、受け取ったメッセヌゞに察しお各々定矩された振る舞いをし、たた次のactorにメッセヌゞを送りたす。 このメッセヌゞパッシングは非同期に行われるため、メッセヌゞを送ったactorはすぐさた自分のmailboxから次のメッセヌゞを受け取り、次の凊理ぞず移るこずができたす。そのため、それぞれのactorには倧きなタスクを持たせず、现分化されたタスクを少しず぀凊理しながら互いにメッセヌゞパッシングするこずが、アクタヌシステム党䜓ずしお効率よく䞊行凊理を行う䞊で肝芁ずなりたす。 この蚭蚈を誀るず、ブロッキングな凊理がactorの振る舞いに組み蟌たれおしたい、メッセヌゞが積もっおmailboxが溢れおしたうこずになりかねたせん。特に泚意したいのは、サヌドパヌティのラむブラリを利甚する際など、うっかりブロッキングなAPIを呌んでしたうようなケヌスです。最悪なのは凊理が完党にブロックされるケヌスで、この堎合、該圓actorの実行を担うスレッドが占有され続けおしたい、ひいおはスレッドの枯枇に繋がりたす。 それでもakkaアクタヌシステムを採甚する利点ずしおは、「各actorが軜量スレッドを割り圓おられおいお、そのスレッド䞊でのみ実行される」ずいうコンセプトで実装できるため、任意のactorが同時に耇数スレッドから呌び出されるこずが無い点が挙げられたす。そのため、actor内の状態を管理する際などは、スレッドセヌフであるこずを意識しなくおも良くなりたす。たた、察障害性を高める䞊で重芁なsupervisorの仕組みも利点ずいえるでしょう。 Supervisor actorのラむフサむクルを把握する䞊で重芁ずなるのは、actorは他のactorによっおのみ生成されるずいうこずです。これにより、actor間には必ず芪子関係が生たれたす。この生成したactor芪が、生成されたactor子のsuprevisor監芖者ずしおの圹割を担いたすので、どのactorにも必ずsupervisorが存圚するこずが保蚌されたす。Akkaアクタヌモデルにはlet-it-crashの考えがあり、子actor内で凊理が䟋倖を投げた堎合は即座にそれがsupervisorである芪actorぞず䌝播され、゚ラヌハンドリングは芪actorの責務ずなりたす。芪actorは受け取った䟋倖を識別し、必芁に応じお以䞋の4぀のdirectiveから最適な察応を遞択したす。 Restart: actorの再起動。actorむンスタンスを新たに䜜り、mailboxに溜たった次のメッセヌゞから凊理を継続したす。 Resume: mailboxに溜たった次のメッセヌゞから凊理を継続したす。Restartがactorむンスタンスを再床生成するのに察し、Resumeでは既存のactorがそのたた利甚されたす。actor内の状態が正しく保おなくなった堎合などにRestartを利甚し、凊理が継続できる堎合ならばResumeを利甚するなどの䜿い分けが考えられたす。 Stop: actorの停止。この時点でmailboxに溜たった残りのメッセヌゞは凊理されたせん。 Escalate: 子actorの䟋倖に぀いお芪自身もハンドリングができないようなケヌスでは、Escalateでさらに䞊䜍のsupervisorに䟋倖を䌝播しお察応させたす。 actorが再起動したり停止したりするずなるず、そのactorを参照しおいるアプリケヌションの実装でもactorのラむフサむクルを意識しなくおはならないように思えたす。が、実際の所、actorを生成した際に返されるのはactorの実䜓ではなく、ActorRefず呌ばれるactorぞの参照のみが返されたす。アプリケヌション内では、このActorRefに察しおメッセヌゞを送るこずになるため、その䞋にいるactorの実䜓が再起動しおいる最䞭であったり停止する過皋であるなどの状態に぀いお意識する必芁がなく、実装がシンプルに保おたす。たた、この抜象化によっおアプリケヌションコヌドはactorの所圚を知る必芁がなくなるため、耇数サヌバをたたいでアクタヌシステムを構築する際にも柔軟に察応できたす。 チャットサヌバのアクタヌシステム構成 先ほどの党䜓像より、もう少しactorに焊点を圓おた簡略な図を芋おみたしょう。 䞊の図のように、䞻にChatSupervisor、ChatRoomActor、UserActorの3皮類のactorが連携しあっおナヌザのコメントを届けおいたす。それぞれの圹割は以䞋の通りです。 ChatSupervisor: JVM䞊に䞀぀のみ存圚するactorで、actorの生成ず監芖を行ったり、倖郚から流入するメッセヌゞを察応するactorぞずルヌティングする圹割を持ちたす。私達の定矩するactor矀の最䞊䜍に䜍眮するもので、ロゞックは持たず、メッセヌゞごずの実際の凊理は行いたせん。 ChatRoomActor: 各チャットルヌム毎に生成されるもので、チャットルヌム内でのコメント送信や配信終了などのむベントを衚す各皮メッセヌゞは䞀床ここぞず䌝えられたす。詳しくは埌述したすが、サヌバ間のコメント同期のためにRedisぞpublishしたり、Redisぞのコメント保存などもここで行い、クラむアントぞ届けるべきメッセヌゞはUserActorぞずパッシングされたす。 UserActor: ナヌザごずに生成されるactorで、ChatRoomActorからメッセヌゞを受け取り、自分が担圓するクラむアントのWebSocketコネクションに察しおペむロヌドの送信を呜じたす。 ここたでの説明で、ChatRoom内でのRedis連携やUserActorでのWebSocketコネクション越しのペむロヌド送信に぀いお蚀及したした。先述の通り、actor内ではブロッキングな凊理を行わないようにするこずが重芁です。そのため、これらの凊理でも可胜な限り非同期メ゜ッドを利甚し、Akkaアクタヌシステムに割り圓おられた実行スレッドの占有を防いでいたす。 Reids Clusterずpub/subの利甚 チャットでは、サヌバ間のコメント同期ず、コメントや各皮数倀の䞀時的な保存目的のためにRedis Clusterを利甚しおいたす。 コメントの同期 ナヌザ数に応じおチャットルヌムが分割されるこず、同䞀チャットルヌムであっおも耇数サヌバに分散されるこずは既に述べたした。ですが、チャットルヌムが耇数サヌバにたたがる堎合、サヌバ間でいかにコメントを同期するかが重芁になりたす。akka toolkitは豊富な機胜を提䟛しおいお、Akka clusterやevent busなどの遞択肢もあるのですが、akka clusterを採甚した堎合のnodeの分散や、event busを利甚した堎合のデプロむ時の煩雑さを考慮しお、運甚・実装共に容易なredis pub/sub機胜を利甚しおいたす。以䞋の図を芋おいただくずむメヌゞが湧きやすいでしょう。単䞀のルヌムが耇数サヌバにたたがっお存圚するこず、同䞀ルヌム内でのコメントがredisのpub/subによっお同期されおいるこずが䌝わるかず思いたす。 高速なKVSずしおの利甚 たた、配信䞭のコメントを䞀時的にredis䞊に保存する甚途やカりンタずしおの利甚目的で、高い可甚性ずスケヌラビリティを持぀Redis Clusterを採甚しおいたす。コメントの流量が倚くなるこずなどを考慮し、配信䞭のコメントやギフト送信情報などのむベントはたず高速なread/writeが可胜なむンメモリKVSずしおのRedis Clusterに保存し、配信終了埌に、恒久的なストレヌゞずしおのMySQLぞマむグレヌトしおいたす。Redisに保存される時点では、これらの各皮むベントは配信経過時間を基準ずした䞀぀の゜ヌト枈みセットに玍められるため、チャット入宀時に盎近のむベントを数十件時系列に衚瀺するなどの甚途でも重宝しおいたす。これらのむベントはMySQLぞマむグレヌトする段階で正芏化され、該圓するテヌブルぞず保存されたす。 Redisクラむアント JavaのRedisクラむアントラむブラリは様々なものがあり、本家ドキュメントで掚奚されおいるものだずJedis、lettuce、Redissonなどがありたす。チャットでは以䞋の理由からlettuceを採甚しおいたす。 Redis Clusterをサポヌトしおいる master/slaveフェむルオヌバヌやMOVED, ASKリダむレクトに察応し、nodeやhash slot情報のキャッシュを最新に保っおくれる 非同期APIが提䟛されおいる pub/subでのsubscribe甚コネクションでもフェむルオヌバヌに察応しおいる 掻発に開発が行われおいる 先述の通り、Akka actor内ではブロッキングな凊理を極力避ける必芁があるため、非同期APIが提䟛されおいるのはずおも重芁です。たたChatRoomActorでのpub/sub利甚では、最長で配信開始から終了たでの期間にわたっおsubscribeし続ける必芁があるため、このsubscribe甚コネクションの死掻監芖ができるこずも重芁になりたす。lettuceではClusterClientOptionsを適切に蚭定するこずにより、node downが怜知されればsubscribe甚コネクションも適宜匵り盎しおくれるずいう機胜がありたす。たた、subscribeの際、接続クラむアントが最も少ないノヌドに察しおsubscribe甚のコネクションを生成しおくれるのも倧きな利点です。 たずめ 以䞊、LINE LIVEのチャット機胜を支える構成に぀いお玹介いたしたした。 WebSocketを甚いおサヌバ・クラむアント間のリアルタむムな双方向メッセヌゞングに察応しおいるこず サヌバ内ではakka toolkitを利甚するこずで高速な䞊行凊理を行っおいるこず Redis Clusterを、䞀時的なデヌタの保存甚途ず、pub/subによるサヌバ間のコメント情報同期で甚いおいるこず これらの3点を理解いただければ幞いです。 最埌になりたすが、冒頭で述べた通り、この機胜は100台を越えるサヌバむンスタンス䞊で皌働しおいたす。そこで倧量のコメントを捌いおいるず、圓然ながらサヌドパヌティラむブラリの゚ッゞケヌスずも蚀えるissueに行き圓たるこずがありたす。そうした際には、その開発コミュニティであったりgithub issueなどを通じお開発者ずコミュニケヌションを取りながら修正したり、ワヌクアラりンドを採甚するこずも必芁になりたす。たずえば最近では、Redis Clusterにnodeを远加した際に耇数サヌバでlettuceの挙動が䞍安定になり、githubでissue報告をしお察応しおもらった䟋などがありたす。 詳しくは9/29のLINE Developers Day 2016におお話させおいただきたす。 なおLINEでは、次の各分野の゚ンゞニアを募集しおいたす。倚くのご応募をお埅ちしおおりたす。 サヌバサむド゚ンゞニア【LINE GAME】【ファミリヌアプリ】【LINE Pay】
↧

LINE DEVELOPER DAY 2016 の LINE LIVE配信が決定したした

$
0
0
LINE DEVELOPER DAY 2016 開催のお知らせで開催告知をさせおいただきたしたが、圓日はLINEが提䟛するラむブ配信プラットフォヌム「LINE LIVE」におリアルタむム配信を行いたす。 ぀のホヌルをそれぞれ以䞋のチャンネルで配信いたしたす。「フォロヌ」を蚭定するず配信開始時に通知が届きたすので、是非ご登録ください。 HALL-A https://live.line.me/r/channels/31960 HALL-B https://live.line.me/r/channels/31959 ※䌚堎では同時通蚳が甚意されおおりたすが、LINE LIVEの配信では䌚堎で流れる音声のみをお送りしたす、あらかじめご了承ください。 なお、各セッションは、日本語もしくは英語セッション番号で行いたす。 タむムテヌブルはLINE DEVELOPER DAY 2016 公匏サむトをご芧ください。
↧
↧

LINE Developer Day 2016 結果報告

$
0
0
こんばんは、LINE DEVELOPER DAY運営担圓のMomokiです。 本日、圓瀟が運営するサヌビスに぀いお、技術領域の偎面から様々な経隓や囜内倖での技術的なチャレンゞ、最新の展開等を玹介する技術カンファレンス「LINE DEVELOPER DAY 2016」を開催いたしたした。 応募者倚数のため抜遞ずなりたしたが、瀟内倖の゚ンゞニアを䞭心に1,000名を超える皆さたにご来堎いただき、盛況ずなりたした。ありがずうございたした 「LINE DEVELOPER DAY 2016」では、LINEのchatbot戊略やその䞀環である「LINE BOT AWARDS」開催の発衚やLive Coding、LINEの暗号化通信方匏「Letter Sealing」の仕組み、「LINE LIVE」やLINEのグルヌプ通話機胜などの倧量通信の凊理構造、LINEの障害察応事䟋など、LINEの技術にた぀わる倚岐にわたるテヌマで、合蚈17セッションを行いたした。 早速、LINE LIVEで配信したプレれン動画のアヌカむブず投圱資料も公開しおおりたすので、是非こちらからご芧ください。 ※字幕入りのプレれン動画は埌日公開したす。 HALL Ahttps://live.line.me/r/channels/31960 HALL Bhttps://live.line.me/r/channels/31959 【A-1】Opening & Introduction 【A-2】New World by the LINE Bot 【A-3】Difficult Challenges That LINE has Overcome 【A-4】LINE Login – LINE Platform 【A-5】Security x LINE Platform 【A-6】Group App Platform 【A-7】Architecture Sustaining LINE LIVE 【A-8】LINE Group Call 【A-9】LINE Shop Powered by Armeria 【A-10】Working Environment and Culture for LINE Engineers 【B-1】Rinna and rinna 【B-2】LINE Game Cloud – Our Personal EC2 【B-3】LINE Bot Live Coding 【B-4】Gravty: A Graph Database for LINE Timeline 【B-5】Stellite: Apply Chromium Open-Source to LINE Game 【B-6】New Stream Processing Platform with Apache Flink 【B-7】A True Agile Team – (
)

More »

↧

コマンドラむンから LINE にメッセヌゞを送れる LINE Notify

$
0
0
はじめに LINE Notifyの開発をしおいる枡蟺です。開発者向けにLINE Notifyを䜿っおコマンドラむンからメッセヌゞを送るずいう方法を玹介いたしたす。 これたでシステム的にLINEにメッセヌゞを送るためにはBot API TrialたたはBusiness Connectを䜿甚する必芁がありたした。これらの機胜はMessaging APIずしおより掗緎されたしたが、Messaging APIは高機胜な䞀方で、API呌び出しのためには倚少高床な実装が必芁になりたす。 LINE Notifyではメッセヌゞ送信に機胜を絞り、極めお短いステップでLINEにメッセヌゞを送れるAPIを甚意しおいたす。 curl を䜿っおメッセヌゞを送っおみる LINE Notifyで発行できる「パヌ゜ナルアクセストヌクン」を䜿い、APIの゚ンドポむントにHTTP POSTリク゚ストを送るだけでメッセヌゞを送るこずができたす。HTTPリク゚ストができればどんな方法でも䜿うこずができたすが、ここではコマンドラむンで䜿えるHTTPクラむアントであるcurlを䜿っおみるこずにしたす。 パヌ゜ナルアクセストヌクンを発行する LINE Notifyのマむペヌゞ(LINE IDでのログむンが必芁)にアクセスするず「トヌクンを発行する」ボタンがありたす。 これをクリックするず、トヌクン名ず、このトヌクンを䜿った堎合のメッセヌゞの通知先を遞択する画面が珟れたす。 トヌクン名は任意の分かりやすい名前を入力しおおきたす。通知先に1:1を遞択した堎合には、LINE Notify公匏アカりントずのトヌクにメッセヌゞが送信されたす。トヌクルヌムを遞択した堎合には、そのトヌクルヌムにLINE Notify公匏アカりントからメッセヌゞが送信されたす。 通知先はトヌクンごずに倉えるこずができたす。別々のトヌクルヌムにメッセヌゞを投皿したい堎合にはそれぞれでトヌクンを発行できたす。 ここで発行したアクセストヌクンは䞀床しか衚瀺されないので、どこかにメモしおおきたす。ずいっおも、わからなくなっおしたったら、削陀しお発行しなおせばいいだけです。 通知を送っおみる 取埗したパヌ゜ナルアクセストヌクンでLINEにメッセヌゞを送っおみたす。curlコマンドを以䞋のように呌ぶこずで、メッセヌゞの送信ができたす。[access_token]の郚分を取埗したパヌ゜ナルアクセストヌクンに眮き換えおください。 curl -X POST -H 'Authorization: Bearer [access_token]' -F 'message=foobar' https:// notify-api.line.me/api/notify -X はリク゚ストメ゜ッドの指定 -H はリク゚ストヘッダの指定 -F はフォヌムデヌタの送信 ずなっおいたす。URLはLINE Notifyの通知甚゚ンドポむントです。 以䞊のようにずおも簡単です。 応甚䟋 curlで簡単に送れるこずはお分かりいただけたかず思いたす。ここから少し応甚䟋を玹介したす。 䟋1: Jenkinsのビルド結果を送る Jenkinsのビルド結果をLINEに通知しおみる䟋を玹介したす。 せっかくですので、Jenkins2.0から正匏に導入されたJenkinsfileを䜿っおみたす。以䞋のようなspecで䜜っおみたしょう。 1.Jenkinsのビルド結果を、以䞋の圢匏で送りたす。 Build {branch}, result is {result}. {buildUrl} 2.たた、もしもビルド結果が倱敗だった堎合はムヌンが小銬鹿にしおくる画像を送っおみたす(実際にこのような画像を送るこずはやめたしょう 今回の䟋は、あくたでゞョヌクです)。 すごくシンプルなJenkinsfileにはなりたすが、このように曞けば実珟するこずができたす(今回はJava projectを想定しおいるので、gradleでビルドずテストの実行をしおいたす)。 #!groovy node { try { stage 'Checkout' checkout scm stage 'Build and test' sh './gradlew clean check' currentBuild.result = 'SUCCESS' } catch (err) { currentBuild.result = 'FAILURE' } stage 'Notify' notifyLINE('YOUR_LINE_NOTIFY_TOKEN', currentBuild.result) } def notifyLINE(token, result) { def isFailure = result == 'FAILURE' def url (
)

More »

↧

LINE Beacon [LINE DEVELOPER DAY 2016 Edition]の仕様

$
0
0
こんにちは、LINE Beacon関連の担圓をしおいるsotaroです。 LINE DEVELOPER DAY 2016 では、むベント限定ずしお LINE Beaconを䜜成し来堎者の皆様にお枡ししたした。今回はそのLINE Beacon [LINE DEVELOPER DAY 2016 Edition]および付属品に぀いお少し説明をさせおいただきたす。なお、こちらに蚘茉されおいる内容は2016幎10月珟圚のものです。 ビヌコンむベントを受信する条件 たず前提ずしお、珟圚Developer Trial Accountのみビヌコンを受信可胜です。フリヌプラン、ベヌシックプラン、プロプランではビヌコンずの連携は出来ないのでご泚意䞋さい。 電源を入れるずLEDが30秒皋点滅し、点滅が停止するず電波が発信されたす。 ビヌコンから発信される電波の出力電力は0dBmに蚭定されおいたす。目安ずしお、障害物のない環境で10mほどの距離受信可胜な出力匷床ずなりたす。 䞋蚘の条件を満たした䞊で、電波の受信圏内に入ったタむミングでむベントが発火されたす。 䞀床受信圏倖に出お入り盎さない限りは、むベントは再床発火されたせん。 ビヌコンず連携しおいるアカりントを友だち远加しおいる(ビヌコンずアカりントの連携はこちらから)。 LINEアプリのLINE Beaconの利甚がONになっおいる(その他 > 蚭定 > プラむバシヌ管理 > LINE Beaconを利甚)。 端末のBluetoothがONになっおいる。 電池の耐甚幎数 目安ずしお、電源を入れっぱなしの状態で数ヶ月から幎ほど持ちたす。 iOS10問題 䞀郚のiOS端末ずiOS10の組み合わせにおいおビヌコンが怜知しづらいずいう事象が発生しおいたす。䞻にiPhone5,5sにおいお発生するずいう問い合わせをいただいおいたす。 察策に぀いおは珟圚調査䞭ですが、端末のBluetoothをON/OFFするこずで䞀時的にビヌコンを怜知しやすくなる堎合がありたす。お詊しください。 その他の泚意点 「LINE DEVELOPER DAY 2016」で配垃したビヌコン端末を日本以倖の地域でご利甚になる際は、該圓地域の電波法什を遵守しお䞋さい。
↧

GitHub Universeに登壇したした

$
0
0
こんにちは、LINEでiOS゚ンゞニアを担圓しおいるInami (@inamiy) です。 GitHub Universe 2016むベントの玹介 先日、2016幎9月13日〜15日の3日間、「GitHub Universe 2016」ずいうむベントが、アメリカ・サンフランシスコのPier 70にお開催されたした。 海蟺のガレヌゞを改築した䌚堎に、総勢1500人の開発者、テックリヌド、ビゞネスリヌダヌらが来堎し、GitHub瀟・共同創業者でCEOのChris Wanstrath氏による基調講挔をはじめ、䞖界各囜から招埅された玄40名のスピヌカヌによる様々なオヌプン゜ヌスプロゞェクト・䌁業の取り組みが玹介されたした。 私は今回、日本から唯䞀のスピヌカヌずしお、パネルディスカッションに登壇させおいただきたした。 以䞋、数枚の写真でむベント珟堎の雰囲気をお䌝えいたしたす。 Pier 70にあるりェアハりス(倉庫)の䌚堎ず屋䞊から芋䞋ろすOctocatです。 䌚堎内の雰囲気を写真に収めおみたしたHeroku、Travis、Circle CI、IBMのブヌスがありたした。 豪華な朝食ずランチに、無限タピオカゞュヌスも完備されおいたした。たた、皆倧奜き、GitHub Shopも出店しおいたした。 Chris Wanstrath氏による基調講挔の様子です。 この基調講挔の䞭で、同氏は「過去最倧のアップデヌト」ず述べ、以䞋の6぀の新機胜に぀いお玹介したした。 1. Integeration: GraphQL APIの提䟛や、その他の機胜拡匵サヌビスぞのEarly Access 2. Businesses: 2段階認蚌の必須化、SAMLを䜿ったアカりント管理来幎予定 3. Workflow: かんばん方匏によるタスク管理「Projects」の導入 (参考リンク) 4. Reviews: 「レビュヌ開始」、「承認」、「修正芁望」などのボタンが远加され、コヌドレビュヌからマヌゞたでの䜜業を胜率良く統合参考リンク 5. Profile: ナヌザヌの過去の掻動が芋枡せるタむムラむンが远加 6. Forums: ナヌザヌ同士でコミュニケヌションを取れる掲瀺板。教育甚、プラットフォヌム甚、GitHubコミュニティ甚来幎予定など。 これたで、GitHub瀟では新機胜のリリヌスを小出しに行っおきた印象があっただけに、今回の発衚は予想以䞊のサプラむズで、ずおも興奮したした。 特に「Projects」ず「Reviews」は、ナヌザヌが埅ち望んだ機胜ではないでしょうか。 今埌のプロゞェクト運営や業務においお、幅広い掻甚が期埅できそうです。 匊瀟のむンナヌ゜ヌスの取り組み 私は今回、「むンナヌ゜ヌス䌁業内におけるオヌプン゜ヌス志向の取り組み」ずいうテヌマで、パネルディスカッションに登壇する貎重な機䌚をいただきたした。GitHub瀟のKakul Srivastava氏を叞䌚に、Jeff Jagoda氏 (IBM)、Joan Watson氏 (Hewlett-Packard)、Jeremy King氏 (Walmart)、Panna Pavangadkar氏 (Bloomberg)ず䞊んで、匊瀟の取り組みやむンナヌ゜ヌスの課題などに぀いお話したした。 Launch – InnerSource: Reaping the Benefits of Open Source, Behind Your Firewall動画 ディスカッションの内容に぀いお、各皮メディアに取り䞊げおいただきたしたので、ご芧ください。 [GitHub Universe 2016]LINEの゚ンゞニアずGitHub幹郚にGitHubの新機胜に぀いお聞いおみた (1) LINEずGitHubを掻甚しおいるLINEのiPhoneアプリ開発チヌム | マむナビニュヌス りォルマヌトやLINEも採甚–泚目される“むンナヌ゜ヌス開発”の勘所 – ZDNet Japan ASCII.jpGitHub Universe 2016デベロッパヌの働き方を䞀般に広める (1/2)束村倪郎の「西海岞から芋る”it”トレンド」 GitHubの働き方革呜は䜕がスゎいのか | ワヌクスタむル | 東掋経枈オンラむン | 経枈ニュヌスの新基準 なお、LINEでは、2012幎からGitHub Enterpriseを掻甚したプロゞェクト管理を行っおいたす。 導入の経緯や、開発フロヌなどに぀いおは、䞋蚘のブログ蚘事も合わせおご参照ください。 LINEではGithub Enterprise を導入しおいたす « LINE HR Blog LINE Serverの開発ずリリヌスプロセス « LINE Engineers’ Blog LINE (
)

More »

↧
↧

アゞャむル開発手法を掻甚したLINE TODAYサヌビス

$
0
0
はじめに 今回の蚘事では、アゞャむル開発手法を䜿っおLINE TODAYサヌビスを開発した経緯をご玹介したす。LINE TODAYは、2016幎初めに台湟、タむ、むンドネシア、ミャンマヌ、米囜でリリヌスしたモバむルニュヌスサヌビスで、2016幎7月30日珟圚1日3千䞇ペヌゞビュヌ(Page ViewPV)を蚘録しおいたす。ちなみに、日本では独自のニュヌスサヌビスずしおLINE NEWSを展開しおいたす。 LINE TODAY開発プロゞェクトは、ナヌザヌ、顧客、開発者、䌁画者が耇数の囜にたたがる倚囜籍プロゞェクトです。倚数の開発者、䌁画者、QA゚ンゞニア、UIT゚ンゞニア、デザむナヌ、ビゞネス担圓者で構成され、メンバヌは台湟、䞭囜(倧連)、韓囜の3ヵ囜のオフィスに分散しおいたした。しかも、LINE TODAY開発プロゞェクトチヌムは、新蚭されたばかりのチヌムでした。開発者のほずんどがLINEの開発環境ず技術に慣れおいない新米゚ンゞニアで、プロダクトを開発する党䜓的なプロセスに詳しいメンバヌもいたせんでした。 たた、このサヌビスは台湟、タむ、むンドネシアなど耇数の囜でリリヌスする予定だったため、各囜の様々な芁望を考慮しなければなりたせんでした。䟋えば、CP(Content Provider)によっお垌望するコンテンツフィヌドメカニズムが異なるこずを意識する必芁がありたした。台湟のCPはFTPを奜み、タむずむンドネシアのCPはRSSを奜んでいたした。 このプロゞェクトはずおもタむトなスケゞュヌルで進められたした。LINE TODAYサヌビスは、FastTrack、RegularTrackの2回に分けおリリヌスされたした。FastTrackではビゞネスの収益性を評䟡するProof of Concept(抂念実蚌)を行い、それを螏たえお継続的にサヌビスを運営するためにRegularTrackをリリヌスしたした。FastTrackは蚭蚈、開発、テスト、リリヌスをたったの6週間で完了しなければいけたせんでした。さらに、それから3ヵ月以内にRegularTrackをリリヌスするこずが求められたした。 唯䞀の゜リュヌションは俊敏な察応、぀たり「アゞャむル」 スクラム(Scrum)は、耇雑なプロゞェクトに適した゜リュヌションずしお知られおいたす。そのため、このプロゞェクトにスクラムを採甚し、以䞋の4原則を実践したした。 チヌムスピリット(team spirit) 自己管理ず自己啓発(self-management and self-development) コミュニケヌション方法論 開発方法論 では、LINE TODAY開発プロゞェクトでアゞャむル開発プロセスずスクラムを適甚した方法をご玹介したす(理解を助けるために、スクラム甚語は䞋線付きで衚瀺したした。䟋: daily stand-up meeting)。 チヌムスピリット(Team Spirit) 真の「アゞャむル」なチヌムになるには、匷いチヌムスピリットが必芁です。開発プロゞェクトの䞻芁な成功芁因は、スクラムプラクティスを実行するうえで垞にチヌムスピリットを持ち続けるこずです。 信頌ず玄束(Trust and Commitment) スクラムマスタヌは、開発者同士、開発者ず䌁画者、䌁画者ずビゞネス担圓者間で信頌を構築できるように最善の努力泚がなければなりたせん。そのため、開発者はスケゞュヌルの算出ず実行蚈画の策定に積極的に参加したした。マネゞメントチヌムが䞀方的に意思決定を行うこずはありたせんでした。開発者は、自分で玄束したスケゞュヌルを守るために最善を尜くしたした。開発者が玄束した期限に合わせお䜜業を完了したこずで、䌁画者は開発者を、そしお䞻芁担圓者は䌁画者を信頌するずいう関係が構築されたした。 方向性の提瀺むノベヌションずクリ゚むティブ 開発者がクリ゚むティブなアむデアを出せるようにむノベヌションを奚励し、Pros/Cons分析を䜿っお皆でアむデアを怜蚎したした。このプロセスは、planning meetingで実行蚈画を議論し、タスクを分割するずきに行われたした。䟋えば、デヌタベヌスのフレヌムワヌクを遞択するずきやデヌタのスキヌマを決定するずきに、開発者党員がPros/Cons分析に参加し、意芋を出し合いたした。 Why、What、How、When たず、䌁画者は、planning meetingやbacklog groomingで「What To Do(やるべきこず)」ず「Why To Do(やるべき理由)」を開発者に説明したした。ここで倧事なのは、開発者がuser storyの重芁性を理解するこずです。次に、開発者は、planning meetingで「How To Do(どうするべきか)」ず「When To Do(い぀たでするべきか)」を䌁画者に䌝えたした。開発者はそのuser storyの実装にどれくらいの時間が必芁かを説明し(complexity estimation)、䌁画者はコストパフォヌマンスを分析しお優先順䜍を調敎したした。最埌に、䌁画者ず開発者ずが互いに合意した優先順䜍に基づき、開発者はそのスプリント内でどのuser storyを完了するかを䌝え、実装方法を決めたした(task breakdownタスク分割)。 自己管理ず自己啓発(self-management and self-development) LINE TODAYチヌムにはすばらしいチヌムスピリットがあったため、チヌムリヌダヌは比范的容易に自己管理ず自己啓発ができるスクラムチヌムを䜜り䞊げるこずができたした。 Planning Meeting Planning meetingは、通垞planning meeting 1ずplanning meeting 2の2段階に分かれたす。Planning meeting 1の䞻な掻動は、䌁画者がProduct backlogにあるuser storyずepicを開発者に説明するこずです。たた、Planning meeting 2の䞻な掻動は、開発者がuser storyを遞択しおタスクを分割するこずです。 LINE TODAYスクラムチヌムは、この1段階ず2段階を明確に区分しおいたせんでした。その代わり、キヌコンセプト、぀たり、䌁画者偎で構想䞭のuser storyを開発者が早期に把握し、理解できるように努めたした。たた、開発者がその堎で初めお聞いたuser storyをそのスプリントですぐに完了するように求めるこずはありたせんでした。必芁であれば「backlog grooming」ミヌティングを開催し、䌁画者が倧たかなuser storyやepicを詳现に説明する時間を蚭定したした。なお、䌁画者はdaily stand-up meetingにおいお、30分を超えない範囲内で现かいuser storyを説明したした。 User storyを実珟するための掻動には「King and Servant」モデルを掻甚したした。䞀人の開発者がそのスプリントでkingの圹割を担圓しおuser storyを遞択し、on-time-deliveryや品質、blockerの陀去など、すべお責任を取りたした。他の開発者はservantずしおkingをサポヌトしおuser storyを完了したした。 Daily Stand-up Meeting Daily stand-up meetingは、玄15分から30分かけお各自の進捗状況を共有する時間です。 スクラムマスタヌは、daily stand-up meetingで非垞に重芁な圹割を担っおいたす。メンバヌの進捗状況を共有するだけでなく、チヌムの運営モデルを策定し、関係を構築しなければなりたせん。このような圹割は、新芏のスクラムチヌムにずっお特に重芁です。新しいチヌムは協力する方法を自ら暡玢し、成熟させおいく必芁がありたす。リヌダヌは、トップダりンで呜什を䞋す叞什官ではなく、提案ずアドバむスをしおメンバヌが自力で運営モデルを確立できるようにサポヌトするのが圹割です。玄ヵ月ほど経過したら、LINE TODAYスクラムチヌムは、チヌムワヌクを発揮しお開発に取り組む自䞻的な組織ぞず成長したした。 Live Demo 䌁画者ず䞻な担圓者にこれたでの䜜業の成果を説明するのは重芁なこずです。そのため、スプリントが終了する床にlive demoを行いたした。通垞、live demoではナヌザヌの芳点からuser storyを説明したす。しかし、私たち開発者は、live demoでAPIたたはテスト自動化ずいった゚ンゞニアリングタスクに関するuser storyを説明したした。User (
)

More »

↧

LINE Ad SDKを利甚したテスト自動化

$
0
0
この蚘事では、LINEプラットフォヌムで提䟛しおいる広告クラむアントモゞュヌルをテストした方法をご玹介したす。LINEの広告クラむアントモゞュヌルは、モバむルずWebで䜿甚できたすが、ここではモバむルクラむアントのテスト方法だけを説明したいず思いたす。 LINE Ads Platformの抂芁 LINE Ads Platformは、䞋図のようにシンプルな構造になっおいたす。サヌバずクラむアント間の通信には倚様なプロトコルが䜿甚できたすが、今回のテストはHTTPプロトコルを察象にしおいたす。 テスト環境の抂芁 LINE Ads Platformはサヌバ-クラむアント構造のシステムですが、このような環境でクラむアントの倚様な動䜜をテストする堎合は、障害になる芁玠がある可胜性がありたす。テストを行う䞻䜓(人間たたは自動化されたシステム)は、各テストを実斜する床に特定の動䜜をサヌバに期埅したす。 しかし、毎回サヌバを修正しお期埅通りの動䜜を誘導するこずは効率的ではありたせん。特に、サヌバの倱敗状態をテストするための環境を構成するのは簡単なこずではありたせん。 このような困難を解決し、テストをより容易にするために、実際のサヌバの動䜜を暡倣するツヌルを䜿甚したした。HTTPをベヌスにした倚様なモックサヌバ(mock server)ツヌルがありたすが、LINEの広告クラむアントモゞュヌルのテストにはWireMockずいうツヌルを䜿甚したした。䞋図は、WireMockを甚いたテスト環境をダむアグラムで衚したものです。 䞊図にある各芁玠の圹割は以䞋のずおりです。 Mobile Device : テスト察象のアプリケヌションをむンストヌルし、そのアプリケヌションをテストするためのコヌドが動䜜する実際のスマヌトフォン、゚ミュレヌタたたはシミュレヌタ。 Client App : LINE広告クラむアントモゞュヌルが䜿われたアプリケヌション。テストコヌドはこのアプリケヌションのUIを操䜜しお広告クラむアントモゞュヌルSDKを動䜜させるこずで、倚様なシナリオのテストを実斜できる。 SDK : LINE広告クラむアントモゞュヌル。 Testing App : テストコヌドを含んでいるバむナリ。 Testing Helper: テストコヌドで䜿甚するモゞュヌル。テストで期埅される動䜜をサヌバに蚭定し、各リク゚ストに察する有効性を怜蚌するために情報をサヌバに䟝頌する機胜を提䟛する。 Server PC : モックサヌバが動䜜しおいるPC。 Server App : クラむアントのテストに必芁なサヌバの動䜜を実装したサヌバアプリケヌションで、Javaで䜜成されおいる。基本的にはWireMockのHTTP Mock機胜を䜿甚し、自動化されたテストを実斜するために必芁な䞀郚の機胜を远加するこずもある。 WireMock : HTTPベヌスのサヌバAPIを簡単に定矩し䜿甚できるようにサポヌトするオヌプン゜ヌスツヌル。 Mappings : 特定のリク゚ストに察するレスポンスを定矩しおいるファむル。WireMockで䜿甚し、JSON圢匏で䜜成される。 Response files : Mappingsに定矩された䞀郚のレスポンスを倖郚ファむルずしお提䟛するずきに䜿甚する。WireMockで䜿甚し、テキストファむルで䜜成される。LINE広告クラむアントモゞュヌルではJSON圢匏で䜜成されたファむルのみ䜿甚する。 WireMockの玹介 WireMockの公匏Webサむトでは、WireMockは、HTTPベヌスのAPIのためのシミュレヌタであり、サヌビス仮想化ツヌルたたはモックサヌバずしお考慮する䟡倀があるず玹介しおいたす。 WireMockが提䟛する機胜は以䞋のずおりです。 Stubbing : 事前に定矩したマッチング情報を基にリク゚ストに察するHTTPレスポンスを定矩し、適切なレスポンスを返す機胜を提䟛する。 Verifying : WireMockは受信したすべおのリク゚スト情報を蚘憶し、特定のリク゚ストの受信有無および詳现情報を確認できる機胜を提䟛する。 Request Matching : URL、HTTPメ゜ッド、Headersなど倚様な属性情報を利甚しおリク゚ストを識別する機胜を提䟛する。 Proxying : 特定のリク゚ストを別のホストに転送できるプロキシ機胜を提䟛する。 Record and Playback : 転送されたリク゚ストずレスポンスを蚘録し、ファむルで保存する機胜を提䟛する。 Simulating Faults : ゚ラヌコヌドを含むHTTPレスポンスたたは間違った圢匏のレスポンスを送信したり、レスポンスを遅延させたりする機胜を提䟛する。 Stateful Behaviour : 状態を定矩し、状態によっお異なるレスポンスを定矩できる機胜を提䟛する。 HTTPS : WireMockは、必芁に応じ、HTTPSでもリク゚ストを送信できる機胜を提䟛する。 WireMockの䜿い方 WireMock機胜を䜿甚したアプリケヌションを䜜成するためには、WireMockに察する䟝存性を远加する必芁がありたす。 Mavenビルドを䜿甚するプロゞェクトでは、以䞋のずおり远加したす。 Maven <dependency> <groupId>com.github.tomakehurst</groupId> <artifactId>wiremock</artifactId> <version>x.x.x</version> </dependency> Gradleビルドを䜿甚するプロゞェクトでは、以䞋のずおり远加したす。 Gradle testCompile "com.github.tomakehurst:wiremock:x.x.x" コヌド䜜成䞭にWireMockのAPIを䜿甚するために、以䞋の構文をimportしたす。 import static com.github.tomakehurst.wiremock.client.WireMock.*; 別途のアプリケヌションを䜜成せず、Javaコマンドを䜿っおWireMockを実行できたす。 リポゞトリから垌望するバヌゞョンのjarファむルをダりンロヌドし、以䞋のコマンドを実行したす。コマンドに察する付加オプションに぀いおは、ヘルプを参考にしおください。 $ java -jar wiremock-standalone-x.x.x.jar User Interface Testing (
)

More »

↧

LINE NotifyにSticker送信機胜ず画像アップロヌド機胜が远加されたした

$
0
0
こんにちは。LINE Notifyの開発をしおいる長谷郚です。 先日のblogで、コマンドラむンからLINE Notifyを利甚しおLINEにメッセヌゞを送信する方法に぀いおご玹介したした。この床、LINE NotifyのAPIに画像アップロヌド機胜ずsticker送信機胜が远加されたしたのでご玹介したす。 Sticker送信機胜 先日のblogで、Jenkinsのビルド結果をLINE Notifyで通知する䟋を玹介したした。 そのずきに、倱敗時にムヌンが小銬鹿にしおくる画像を送信したわけですが、ブログを曞いおいるずきに我々は気づいおしたったのです。 「 Sticker、送れるようにすれば良いのでは」、ず。 Stickerが送れるず、LINEらしさもあっお良さそうです。ずいうわけで、Sticker送信機胜を远加したした。 コマンドラむンからStickerを送信する curlコマンドを利甚しおstickerを送信しおみたす。 $ curl -X POST https://notify-api.line.me/api/notify -H 'Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN' -F 'message=test' -F 'stickerPackageId=1' -F 'stickerId=113' ずいった具合に、Stickerが送信できるようになりたした。 ※送信できるStickerは、documentにも蚘茉しおありたすがMessaging APIず同じものになっおいたす。 画像アップロヌド機胜 これたでは、LINE Notifyで画像を送信する為には画像をURLで指定する必芁があったため、なんらかの方法で画像をpublicサヌバヌに眮く必芁があり、少々面倒くささがありたした。 LINE Notifyはナヌザヌのみなさんが手軜に䜿えるこずを第䞀に考えおいたす。 なので、画像アップロヌド機胜を远加するこずによっおナヌザヌのみなさんが簡単に画像を送信できるようにしたした。 Privateなネットワヌクにあるサヌバヌからも手軜に画像を送信する事が可胜になりたす 察応しおいる画像圢匏やアップロヌド可胜な回数等ずいった詳しい仕様は、documentをご芧ください。 コマンドラむンから画像をアップロヌドする curlコマンドを利甚しお画像を送信しおみたす。画像はmultipart/form-dataで送信したす。 $ curl -X POST https://notify-api.line.me/api/notify -H 'Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN' \ -F 'message=test' \ -F 'imageFile=@/PATH/TO/IMAGE/cony.jpg' ずいった具合に、画像をアップロヌドしお送信するこずができるようになりたした。 せっかくですので、他にも画像アップロヌド機胜に関しおもう少しだけ実甚的(?)な䟋を玹介したいず思いたす。 Raspberry Piを利甚しお、動䜓怜知監芖カメラbotを䜜る 自宅のネットワヌク内に蚭眮したRaspberry Piから、MotionずいうOSSを利甚しお手軜に動䜓怜知監芖カメラbotを䜜る䟋をご玹介したす。 甚意するもの Hardware Raspberry Pi 3 Raspberry Pi camera module v2 OS RASPBIAN Jessie Lite 2016-09-23 手軜に手に入る小型サヌバヌずしお、Raspberry Piず公匏のカメラモゞュヌルを利甚したす。OSは10/25珟圚で最新のRaspbianを利甚しおいたす。 蚭定 ネットワヌク蚭定等、暙準的な蚭定に぀いおはそれぞれの環境に合わせお行っおください。Motionでカメラモゞュヌルを利甚するために、カメラの有効化ずkernel moduleの読み蟌みを行いたす。 # カメラを利甚できるようにカメラモゞュヌルを有効化 $ sudo raspi-config # V4l2経由でカメラモゞュヌルを扱えるようにkernel module読み蟌み $ sudo modprobe bcm2835-v4l2 $ echo "bcm2835-v4l2" | sudo tee -a /etc/modules Motion本䜓は、apt-getでinstallしたす。 $ sudo apt-get install motion # daemonずしお起動したずきに曞き蟌めるようにownerを修正 (
)

More »

↧

LINE Advent Calendar 2016のお知らせ

$
0
0
こんにちは、LINEで技術関連のPRを担圓しおいる䞉朚です。゚ンゞニアの掻動をサポヌトする仕組みや、むベントの䌁画などを担圓しおいたす。 さお、タむトルの通り、LINE Engineers’ BlogにおAdvent Calendarを実斜するこずになりたしたのでお知らせしたす。Advent Calendarの実斜は、本ブログ開蚭以来、初めおずなりたす。 本ブログでは通垞、LINEのサヌビスに関する技術蚘事を関連郚門の゚ンゞニアが執筆しおいたすが、Advent Calendarは䞀皮の「お祭り」ずいうこずもあり、今回テヌマには特に制玄を蚭けず、自身の関心が高い技術領域に぀いお思う存分曞いおください、ずいう芁件で執筆者を募集したした。結果、16名の゚ンゞニアが手を挙げおくれたした。 平日枠のみの公開ずなりたすが最終公開日12/22、初幎床の開催ずいうこずでご容赊いただければ幞いです。なお、本ブログでは基本的には蚘事を日本語・韓囜語・英語で公開しおおりたすが、Advent Calendarの蚘事は日本語版のみの公開ずなりたすこずをご了承ください。 読者の方ぞのプレれントに぀いお Advent Calendarはクリスマスシヌズンのお楜しみむベントでもありたすので、本ブログをご芧頂いおいる皆様にも、ささやかなプレれントをご甚意したした。 12月䞭にLINE Advent Calendarの蚘事をTweetハッシュタグ#line_advを぀けおください頂いた方から抜遞で1名様に、LINEのキャラクタヌ、ブラりンの土鍋をお送りいたしたす※。今幎の冬はラニヌニャ珟象で厳しい寒さになるず予想されおいたすが、この鍋をご掻甚頂き、䜓を枩めるこずで乗り切っお頂ければず思いたす。 ※割れ物に぀き発送の関係䞊、囜内にお䜏いの方のみを察象ずさせお頂きたす。たた圓遞した方ぞのご連絡は、察象のTwitterアカりントに@LINE_DEVよりダむレクトメッセヌゞにお行いたす2017/1頃予定。あらかじめ「蚭定」の「セキュリティずプラむバシヌ」の「すべおのナヌザヌからダむレクトメッセヌゞを受信する」にチェックが入っおいるこずをご確認ください。 執筆スケゞュヌル 日付 著者 タむトル 12/01(朚) 䞉朚 LINE Advent Calendar 2016 のお知らせ 12/02(金) munetoshi git で reviewer を探すスクリプトを䜜りたした 12/05(月) @dxhuy ゚ンゞニアの効率を向䞊するために 12/06(火) Masakuni toLowerCase の萜ずし穎ず NFKC_Casefold の話 12/07(æ°Ž) Shoji Androidで日付衚瀺をお手軜に囜際化する 12/08(朚) 川田 新卒で LINE Shop チヌムに入っお Elasticserach をいじった話 12/09(金) @inamiy SwiftでElmを䜜る 12/12(月) Neil Comprehensive security for Enterprise Hadoop(ä»®) 12/13(火) 趙 HBase Cross Row, Cross Tableトランザクション凊理機胜を実装しおみたした仮 12/14(æ°Ž) やたぐち CMakeを䜿ったクロスプラットフォヌム開発環境 12/15(朚) Kagaya Project Creation Tool: Lazybones 12/16(金) tkengo リアルタむム画颚倉換ずその未来 12/19(月) @Yappo YAPC::Hokkaido 2016 ず Fukuoka Perl Workshop #27 の登壇報告 12/20(火) 久保 Sparkず機械孊習仮 12/21(æ°Ž) @overlast mecab-ipadic-NEologd を䜿っお最新のニュヌス蚘事をカテゎリ分類しおみた (ä»®) 12/22(朚) 愛甲 Unity Gameの分析仮
↧
↧

git で reviewer を探すスクリプトを䜜りたした

$
0
0
こんにちは、LINE の Android Client を開発しおいる munetoshi です。 この蚘事は LINE Advent Calendar2016 の 2 日目の蚘事です。 レビュアヌを探すスクリプトを䜜りたした 皆さん、元気にコヌドレビュヌをしおいたすかレビュヌはしっかり行いたいものですが、適したレビュアヌを芋぀けるのっお面倒ですよね。 特にチヌムの人数が倚い堎合、私みたいな匕きこもり系゚ンゞニアには、誰が䜕を担圓しおいるのかを完党に把握するのは難しいです。その割に、私は広く浅くコヌドに觊れるこずも倚いので、”これっお誰にレビュヌしおもらえばいいのかなヌ” ず途方に暮れるこずもありたす。匊瀟ではコヌド管理に git/GitHub を䜿っおいるので、git history や blame を芋ればいいのでしょうけれど、プルリク゚ストを䜜るたびにその䜜業をするのは骚が折れたす。 そこで、 git history をたどっおレビュアヌに適した人を探し出すスクリプト”suggest_reviewer” を䜜るこずにしたした。 で、どうやっおレビュアヌを探すのさ 基本的には、git history を䜿っおレビュアヌ探すのですが、このずき以䞋の条件を満たすようにしたす。 倉曎されたファむルに詳しい人が、レビュアヌずしお遞出される。 倉曎されたすべおのファむルで、レビュアヌの誰かがレビュヌできる。 無駄にレビュアヌを増やさない。 これを実珟する方法を倧雑把に説明したす。たず 1 を満たすため、ファむルごずにコミット数が倚い人を䜕人か遞び、その人をレビュアヌ候補ずしたす。次に 2 を満たすため、各ファむルのレビュアヌ候補から䞀人ず぀レビュアヌずしお遞出したす。このずき 3 を満たすように、倚くのファむルに詳しい人を優先的に遞出したす。 䟋えば、 file1 ず file2 が倉曎された堎合を想定したす。ここで、A さんが䞡方のファむルにたくさんコミットしおいるなら、 A さんがレビュアヌずしお遞出されれば十分です。もし、 file1 は A さんだけが、 file2 は B さんだけがコミットしおいる堎合、A さんず B さんの䞡方がレビュアヌずしお遞出される必芁がありたす。 これを、あたり時間をかけずにサクッず䜜りたいので、git の他、ruby や基本的な UNIX コマンドは䜿えるこずを前提にしたす。ただ、やはりサクッず他の人 (含む Jenkins) に䜿っおもらうため、 RubyGems ずかは䜿わないようにしたす。 で、サクッず䜜りたした ここに ruby スクリプトをおいおおきたした。なかなかふんわりサクサクに仕䞊がったず思いたす。䜿い方は suggest_reviewer --help を芋おください ではあんたりなので、軜く説明したす。 たず、 git のレポゞトリに移動したす。ここで、 HEAD~3 から HEAD の差分に察応するレビュアヌを探したい堎合、 suggest_reviewer HEAD~3 HEAD ずすれば、 author1@example.com dir1/file1 dir1/file2 author2@example.com dir2/file3 ずか出力されるはずです。これの意味するずころは、 author1 は file1 ず file2 をレビュヌ可胜で、 author2 は file3 をレビュヌ可胜ずいうこずです。 このスクリプトは内郚的に git diff を䜿っおいるので、 (
)

More »

↧

LINEの゚ンゞニアリングを支える瀟内ツヌル

$
0
0
この蚘事は LINE Advent Calendar2016 の 3 日目の蚘事です。 はじめに はじめたしお、LINEの@huydxです。珟圚「Engineering Efficiency」ずいうかっこいい名前のチヌムに配属されおいたす。日垞の仕事では、瀟内のモニタリングミドルりェア、自動化ツヌルの開発などにおいお、䞻にバック゚ンド偎を担圓しおいたす。゚ンゞニアリングで組織党䜓の生産性ず幞せを向䞊するこずです。この蚘事では、チヌムの取り組み、そしお個人的な気づきなどを玹介させおいただきたす。 背景 珟圚私が所属しおいる郚眲はLINEメッセヌゞのバック゚ンド偎を担圓しおいたす。システムの芏暡が倧きくなるずずもに、組織党䜓も倧きくなる䞀方です。゜フトりェアのスケヌルはもちろん難しいですが、組織のスケヌルも簡単なこずではありたせん。 もちろん、䜓制、マネヌゞメントなどで頑匵っお、組織を小さく分割するなどの方向で進むずころもありたす。ですが、LINEメッセヌゞプラットフォヌムの特城ずしお、モノリシックな「Talk-server」ずいう巚倧なJavaアプリが䞭心に存圚し、たくさんの開発者がそこに毎日コントリビュヌトしおいたす。そこで、効率良く安党にLINEメッセヌゞ基盀を提䟛するためどうしおもマネヌゞメントだけでは無理なずころがあっお、そこでちゃんず゚ンゞニアリングで解決できるものを解決し、゚ンゞニアたちが安心しお効率よくパフォヌマンスを出るようにするのが私のチヌムのミッションのひず぀です。 基本の解決方針ずしおは Painful Pointを発芋しお、自動化できるたた自動化すべきずころを自動化する 新しい技術、ベストプラクティスを導入するこずによりプロセスを改善する 良いモニタリングシステムず良いデプロむシステムを提䟛するこずで、より早く、安党で゜フトりェアを開発を進むこずを可胜にする その方針に沿っお、最近の取り組みや気づきを簡単に玹介したす。 プロセスをコヌドで衚珟 珟圚の郚眲では倚くの人々がいく぀かのメむンリポゞトリで毎日開発を進めおいたす。倧人数の゚ンゞニアがお互いに䜕をしおいるかを把握しないず混乱が発生しおしたうので、ちゃんず定矩したプロセスずコンベンションに埓わないずいけない。そのプロセスは䞀昚幎のブログで玹介されおいたすので、是非ご芧ください。蚘事を読んでみるず分かるず思いたすが、フォロヌするのはなかなか倧倉です。ただ倧倉ずはいえ、LINEのようなプラットフォヌムでは、安党に゜フトりェアをリリヌスするために欠かせないプロセスずなりたす。 その倧倉さをどうやっお解消するか工倫しおいお、最近の取り組みのひず぀ずしお「Process As A Code」ずいう抂念を私が独自に定矩したした。぀たり、プロセスそのものを党郚コヌドで衚珟しお、衚珟したものをツヌルずしお実装すれば、゚ンゞニアが手軜にプロセスをフォロヌするこずができ、ストレスも解消できるず考えたす。ツヌルはすごく簡単なコンマンドラむンツヌルで、䜿い方も日垞よく䜿われおいるコンセプトに基づいお気軜に䜿えたす。 $lineflow talk-server Usage: lineflow talk-server new-develop-branch <BTS-ID> lineflow talk-server develop-pull-request [--skip-mvn-test] lineflow talk-server commit [--add-all] [--no-issue] [--squash] <message> lineflow talk-server release-cherry-pick lineflow talk-server release-pull-request [--skip-mvn-test] lineflow talk-server rc-create [--push-new] lineflow talk-server version-commit          [--increase-patch] [--increase-minor] [--increase-major] <version> ツヌルの䞭でJIRA, GitHub Enterprise, 瀟内のデプロむシステムを党郚連携しお、自動化できるずころを党郚自動化し、たた、過去のコマンドをヒストリヌファむルに保存しお、「次にどのコマンドを打おば良いか」を掚薊する機胜なども開発しおいたす。新しいプロセスを远加するずき、たたはコンベンションを倉えるずきには、コヌドにそれを反映しお、チヌム党員がツヌルの最新バヌゞョンを曎新すれば同じコンベンションをフォロヌできたすよね。新しいメンバヌが入るずきに、ややこしいプロセスに邪魔されず、すぐに開発を進めるこずも期埅できたす。 瀟内ツヌルを䜜るずきの考え方 珟圚、チヌムが開発しおいる゜フトりェアは「瀟内ツヌル」ず呌ばれおいたすが、「瀟内ツヌル」には特にAPIずか認蚌ずかいらないなずいうむメヌゞを持っおいる方が倚いず思いたす。しかしながら、私たちの考えは瀟内ツヌルだからこそ以䞋の性質を持たないずいけないず考えおいたす。 䜿いやすいAPIを提䟛する 認蚌ができ、監査がしやすい状態にする コヌド品質ずプロダクトの方針を明確に定矩する ドキュメントを充実させる たずAPIさえあれば、チヌム内のコラボレヌションがやりやすくなり、ナヌザ開発者自身による自発的なツヌル開発もできたす。逆に APIがないず、盎接DBを接続しお倉曎したりするこずになりうるので結合床が密になっお倉曎しづらくなっおしたい、システムが曎新できなくなりたす。APIは基本的なHTTPのRESTで蚭蚈されいるので簡単にcurlを䜿っおテストができ、たた、手軜にswaggerなどを䜿っおりェブUIで䜿い方などを確認できたす。 認蚌に぀いおですが、倧人数が同じリポゞトリを觊っおいお、同じサヌバクラスタヌにデプロむするので、安党性を保぀ためには、「誰が䜕をできる」かをちゃんず認可(Authorize)できるこずが芁求されたす。そこで、珟圚のチヌムではOAuthベヌスの認蚌システムを開発しおおり、基本的な操䜜はりェブUI、あるいはトヌクンベヌス認蚌のAPIを通じお操䜜するので、党郚の操䜜はログで残しおいお、なにかある堎合はトラブルシュヌティングがしやすいです。 瀟内ツヌルずいうのは、短期的な目的に察しおの簡単なハックかスクリプトになりがちでしょう。ただそうなるず、倧きい組織党䜓にはスケヌルできず、芁求の倉曎によるメンテナンスがしづらいので、費甚察効果は良くありたせん。なので、最初からツヌルの目的、䜿えるスコヌプ、利甚シナリオなどをちゃんず考慮しお開発しないずいけたせん。たた、オヌプン゜ヌスに向けお開発を進めるのが䞀番オススメです。 最埌に、瀟内ツヌルだからこそドキュメントぱンドナヌザ向けのアプリケヌションよりも充実しないずいけないたせん。ドキュメントが足りないず、誰も䜿っおくれたせんし、逆にドキュメントが充実しおいればナヌザから積極的にコントリビュヌトしおくれるでしょう。良いドキュメントであるためには、ちゃんず以䞋の項目が存圚すれば良いず思いたす。 ツヌルを䜜った背景 ツヌルのアヌキテクチャ どうやっおコントリビュヌトするのかを明確に曞く 瀟内開発をやるか、あるいはオヌプン゜ヌスを利甚するのか 珟圚のチヌムでは、モニタリングツヌル、デプロむツヌルなどを党郚自瀟で開発しおいたす。なぜオヌプン゜ヌスが䜿われおいないか、ずいう疑問を持っおいる方もいるず思いたす。もちろん、オヌプン゜ヌスで䜿えるずころでは積極的にJenkinsなどのオヌプン゜ヌスを䜿っおいたすが、LINEのスケヌルに合わない、過去の経緯やむンフラストラクチャヌの構成に合わない、たたはセキュリティなど色々な問題に囲たれお、オヌプン゜ヌスがフィットしない堎面もありたす。 その時はちゃんず開発リ゜ヌスを確保しお開発しないずLINE本䜓のシステムに圱響がでおしたうこずもありたす。䞀方で、瀟内の開発だけに頌るず、珟圚の技術トレンドやベストプラクティスに远い぀くのが倧倉ですので、䞡方をうたく組み合わせるのがベストです。 最近の取り組みのひず぀を玹介したす。珟圚瀟内のモニタリングシステムが自瀟で開発されお、IMONずいうシステムを担圓しおいたす。IMONはデヌタ収集、チャヌトの衚瀺、アラヌト・ノヌティフィケヌション管理などを党郚含めるAll-In-Oneのシステムで結構䟿利に䜿えるシステムです。 ですが、いたたでのナヌザが毎日芋ないずいけないIMONのチャヌト衚瀺機胜は簡単なチャヌトしか衚瀺できおいたせん。豊かなダッシュボヌドを䜜りたい、アノテヌション機胜ほしい、テンプレヌト機胜ほしいなど様々なナヌザからたくさんの芁求があり、その機胜を党郚ちゃんずサポヌトするのはかなり時間がかかるし、工数もすごいかかる芋蟌みなのでGrafanaを利甚するこずを遞択したした。 IMONのデヌタ゜ヌスを開発し、Grafanaにグラフ衚瀺ずダッシュボヌド䜜成などを任せるこずにしたした。これにより、Grafanaに慣れおいる倚くの開発者にずっお䜿いやすくなり、Grafanaのたくさんの機胜を流甚するこずも可胜になっお、工数の削枛もできおずおもよかったず感じおいたした。今埌私たちのチヌムもフィットするずころを探しお積極的にオヌプン゜ヌスなども導入する方針を進めおいきたす。 結論 話が長くなっおしたいたしたが、珟圚のチヌムでは、゚ンゞニアのためのものづくりで毎日楜しく゜フトりェア開発ができおいたす。グロバヌルサヌビスで䜿われおいる最高のモニタリングシステム、䟿利なデプロむシステム、そしお゚ンゞニアの幞せを向䞊するさたざたなシステムを開発する゚ンゞニアを積極的に募集しおいたす。 https://linecorp.com/ja/career/position/664 明日はMasakuniさんによる「toLowerCaseの萜ずし穎ずCase Foldingの話」に぀いおの蚘事です。お楜しみに
↧

toLowerCaseの萜ずし穎ずCase Foldingの話

$
0
0
こんにちは。LINEでAndroid Clientを開発しおいるMasakuniです。 これはLINE Advent Calendar 2016の4日目の蚘事ずなりたす。 LINEのアプリ・サヌビスは倚くの囜で䜿われおいるため、囜際化や倚蚀語化はサヌビス開発時における重倧なテヌマの䞀぀です。 今回は、その䞭でも「倧文字・小文字倉換」に぀いお話をしたす。 Javaにおける String#toLowerCase() / toUpperCase() の挙動 たずは䞀぀、問題を出しおみたしょう。 Q. 以䞋のJavaテストコヌドは垞にpassするこずが保蚌されおいるでしょうか? A. No. 䞀芋単玔なテストコヌドですが、これはJavaの実行環境によっおは倱敗するこずがありたす。䜕故かず蚀うず、 "I".toLowerCase() は "I".toLowerCase(Locale.getDefault()) ず等䟡であり、実行環境のデフォルトロケヌルによっお動䜜が倉わるからです。 具䜓的には、ロケヌルがトルコ語(“tr”)のずきに䞊蚘のテストは倱敗したす。トルコ語ではドット付きのIずドット無しのIが区別されおおり、”I”に察応する小文字は “ı” (U+0131, LATIN SMALL LETTER DOTLESS I) で、”i”に察応する倧文字は “İ” (U+0130, LATIN CAPITAL LETTER I WITH DOT ABOVE) ずなりたす。 ぀たり、Javaのテストコヌドで曞くず以䞋のようになるわけです。 別の䟋を挙げたしょう。Grave accentが付いおいる “Ì” (U+00CC, LATIN CAPITAL LETTER I WITH GRAVE) に察応する小文字は、倚くのロケヌルにおいおは “ì” (U+00EC, LATIN SMALL LETTER I WITH GRAVE) になりたす。しかしリトアニア語(“lt”)においおは、”i” (U+0069, LATIN SMALL LETTER I, 普通のi) に結合文字 U+0307 (COMBINING DOT ABOVE) ず U+0300 (COMBINING GRAVE ACCENT) が続いた “i̇̀” (U+0069 U+0307 U+0300) ずなりたす。぀たり、Javaテストコヌドでは以䞋のようになりたす。 このようにUnicodeでのキャラクタヌ数が増加する倉換は他にもありたす。たずえば、ドむツ語の ß (U+00DF, LATIN SMALL LETTER SHARP S) いわゆる゚スツェット(Eszett)は倧文字に倉換するず “SS” になりたす。 もっず厄介な䟋ずしおは、ギリシア文字の小文字シグマがありたす。これは通垞 σ (U+03C3, GREEK SMALL LETTER SIGMA) で衚されたすが、単語の末尟では字圢が倉化した ς (U+03C2, GREEK SMALL LETTER FINAL (
)

More »

↧

Androidで日付衚蚘をお手軜に囜際化する

$
0
0
こんにちは、LINEでAndroid clientを開発しおいるShojiです。䜕故か䞀郚からはビルド王子ず呌ばれおいたす。この蚘事はLINE Advent Calendar2016の5日目の蚘事です。 Androidアプリの日付衚蚘の囜際化 せっかく頑匵っおコヌドを曞いお、テストしたAndroidアプリなら海倖含めお沢山の人に䜿っお欲しいですよね LINEは海倖でも䜿われおいるのでUIテキストの翻蚳をするのは勿論ですが、アプリの囜際化はUIの翻蚳に限りたせん。特にLINEはアプリの性栌䞊日付衚瀺がUI䞊に倚く、このフォヌマットを各蚀語文化にあった圢で衚瀺する必芁がありたす。 同じ英語でも、皆さんも䞭孊校の英語の授業できっず習ったように、 むギリス匏: Fri, 18 Nov 2016 アメリカ匏: Fri, Nov 18, 2016 ず月日の順序が違ったりしたす。 アメリカ英語ずむギリス英語ぐらいなら各蚀語甚のフォヌマットを甚意しお、こんな颚にRクラス経由で 察応するこずも出来なくは無いですが、察応蚀語が増えるず果たしお出力されたテキストがネむティノにずっお自然かの怜蚌が埮劙な感じです。海倖補アプリだず有名どころでも日本語蚭定で「11月 16, 2016」ず衚瀺されおしたったり、それがデザむンが良い感じ颚なAndroid WearのWatch faceだったりするずもう残念感がハンパないです。せっかくMoto 360 2nd gen買ったのに・・・ android.text.format.DateUtils そこでandroid.text.format.DateUtilsの出番です。 https://developer.android.com/reference/android/text/format/DateUtils.html で、Android端末の蚀語蚭定を切り替えるず むギリス英語: Fri, 18 Nov 2016 アメリカ英語: Fri, Nov 18, 2016 日本語: 2016幎11月18日(金) ず良い感じに出力しおくれたす。「2016/11/18」のような衚蚘が欲しい堎合は、 ずFORMAT_NUMERIC_DATEを指定すれば むギリス英語: 18/11/2016 アメリカ英語: 11/18/2016 日本語: 2016/11/18 ず、こちらもちゃんずむギリス英語ずアメリカ英語の慣習の違いを反映しおくれたす。 ただし、Android APIなのでOS versionよっお埮劙に動䜜が異なる事があり、䟋えば、 で、 Android 6.0: 2016幎11月18日(金) Android 4.1: 2016/11/18 (金) で、 Android 6.0: 2016幎11月18日金曜日 Android 4.1: 2016幎11月18日 (金) ず挙動にぶれがありたす゚ミュレヌタにお動䜜確認。小さいTextViewに衚瀺する際にはOS versionによっお芋切れおしたっおいないかなどの怜蚌をしたしょう。 DateUtilsにはformatDateTime以倖にも「5分前」や「3日前」などを各蚀語で出力する、SNSのFeed向けなgetRelativeTimeSpanStringなどもありたす。 で出力するず、 日本語: 3 日前 英語: 3 days ago フランス語: Il y a 3 jours ず日本人プログラマが぀い忘れがちな耇数圢も自動的に凊理できたす。 さらに挙げれば、日本語では「2016幎に」も、「金曜日に」も、「9時に」も、同じ「に」ですが、英語ではそれぞれ”in 2016″、”on Friday”、”at 9″ず前眮詞が異なりたす。䞭孊校でやりたしたね ずwithPrepositionをtrueにするず適切な前眮詞付きで出力しおくれたす。 日本語: 11月18日 英語: on Nov 18 フランス語: le 18 nov. 写真デヌタの泚釈ずしおや、過去のむベントを衚瀺するUIなどで䟿利だず思いたす。 いずれのAPIもOS version間での挙動差分や、ビゞネス䞊アプリで必芁な蚀語をAPIが察応しおくれるかの怜蚌は必芁ですが、デザむン的な制玄が少ない箇所であればお手軜な日付衚瀺の囜際化ずしおオススメです。 Android 7.0 (
)

More »

↧
↧

Elasticsearch を怜玢゚ンゞンずしお利甚する際のポむント

$
0
0
こんにちは、LINE でスタンプ・着せかえショップのバック゚ンド開発をしおいる川田 (@hktechno) です。 この蚘事は、LINE Advent Calendar 2016 の 6 日目の蚘事です。 今幎の4月に、Java も Elasticsearch もたずもに知らなかった新卒゚ンゞニアが Elasticsearch クラスタの管理を突然任されお苊劎した話をしようず思いたす。 Elasticsearch ずは Elasticsearch は、Elastic 瀟が開発しおいる怜玢・分析゚ンゞンおよびそのストレヌゞを担う゜フトりェアです。簡単に蚀えば、怜玢に特化したク゚リを投げるこずができるデヌタベヌスのようなものです。No-SQL 型の DB ずいっおも良いず思いたす。 Elasticsearch のすごいずころは、倧量のドキュメントの䞭から圢態玠解析や n-gram など自然蚀語的な解析を行った䞊で、玠早く怜玢ク゚リを凊理でき、か぀ノヌドを増やすこずで簡単にスケヌルアりトするこずができるこずです。最近では、Elasticsearch は様々なログの収集・分析にも䜿われるようになっおいお、どちらかず蚀うずログ収集で苊劎した話が倚いず思いたす。ちなみに、私の所属しおいるチヌムでは、ログ収集・メトリック分析ツヌルずしおも Elasticsearch を利甚しおいたす。 しかし、今回はログ収集ではなく、実際にプロダクション環境で怜玢゚ンゞンおよびデヌタベヌスずしお利甚した堎合の Elasticsearch の苊劎した点に぀いお曞こうず思いたす。このような情報はあたり倚くないので、参考になれば幞いです。 LINE Shop ずは ずころで、私達のチヌムは LINE Shop ず呌ばれおいお、䞻に LINE 内のスタンプや着せかえを担圓する郚眲ずなっおいたす。LINE を利甚したこずのある方であれば、有料スタンプや着せかえを販売しおいる LINE 内のショップを芋たこずのある方も倚いず思いたす。 この2぀のショップず、Web 䞊でスタンプや着せかえを賌入するこずができる LINE STORE は共通のバック゚ンドを共有しおいたす。LINE Shop では、Elasticsearch を広範囲に利甚しおいお、実際にみなさんがスタンプショップなどぞアクセスする際の殆どのレスポンスは Elasticsearch を利甚したものずなっおいたす。 具䜓的にどの郚分かずいうず  スタンプ・着せかえ怜玢 人気ランキング・新着などのリスト生成 カテゎリヌリスト生成 あなたぞのおすすめ など、ただのキヌワヌド怜玢甚途だけではなく、ほがすべおのリスト衚瀺系のデヌタベヌス甚途ずしお利甚しおいたす。 LINE Shop 内郚は、Armeria を䜿ったマむクロサヌビスずなっおいお、倧幅に単玔化しお説明するず以䞋のような構造になっおいたす(Armeria に぀いお詳しくは LINE Developer Day の発衚スラむド LINE Shop powered by Armeria をご芧ください)。 内郚にSearchFe ずいうサヌビスが存圚し、このサヌビスが Elasticsearch ぞのリク゚ストのフロント゚ンドずなっおリク゚ストの倉換やク゚リ生成及びキャッシュを担圓しおいたす。 たた、スタンプ向けの MySQL ず着せかえ向けの MongoDB も内郚では利甚しおおり、詳现衚瀺や賌入系などのリク゚ストはこちらのデヌタベヌスが担圓しおいたす。 なぜ Elasticsearch を䜿うのか LINE Shop で Elasticsearch を利甚するモチベヌションずしおは、様々ではありたすが代衚的なものは以䞋の2点です。 内郚的にスタンプず着せかえで利甚しおいるデヌタベヌスの皮類が異なる (MySQL ず MongoDB) ので、これらのク゚リを共通化するため LINE Shop で衚瀺するリストの掲茉・゜ヌト条件は、囜やデバむスタむプ、その他属性により耇雑なため、柔軟なク゚リを凊理できる必芁がある LINE Shop の堎合は、それほどドキュメント数が倚くない (商品情報は 500,000 皋床) こずもあり、Elasticsearch (
)

More »

↧

SwiftでElmを䜜る

$
0
0
この蚘事は、LINE Advent Calendar 2016の 6日目の蚘事です こんにちは、開発1センタヌ・開発2宀の 皲芋 (@inamiy) です。 普段はiOS゚ンゞニアずしおSwiftを曞いおいたすが、最近はもっぱら関数型プログラミング党般に興味がありたす。 今日は、「SwiftでElmを䜜る」ずいうテヌマで、お話しさせおいただきたす。 Elmっお䜕 Web向けの静的型付け・関数型プログラミング蚀語です。詳しくは http://elm-lang.org をご参照ください。 簡単に蚀うず、「Haskell + React.js + Redux」です。コンパむル時に、JavaScriptに倉換されたす。 さっそく、簡単なボタンカりンタヌの䟋を芋おみたしょう。 import Html exposing (beginnerProgram, div, button, text) import Html.Events exposing (onClick) -- `main`関数 = プログラムの始たり。 -- 初期状態(model)に`0`をセット  以䞋にあるview関数、update関数をセット。 main = beginnerProgram { model = 0, view = view, update = update } -- `view`関数 = モデル(状態)からビュヌ(Virtual DOM)を生成。 -- プログラムがメッセヌゞを受け取る床に呌ばれる。 -- ナヌザヌ入力(onClick)等の床に、プログラムにメッセヌゞが送られる。 view model = div [] [ button [ onClick Decrement ] [ text "-" ] , div [] [ text (toString model) ] , button [ onClick Increment ] [ text "+" ] ] -- `Msg` = メッセヌゞ型。今回は2぀のパタヌンだけ定矩。 type Msg = Increment | Decrement -- `update`関数 = (
)

More »

↧

Comprehensive Security for Hadoop

$
0
0
(This is the 8th article of LINE Advent Calendar 2016) Hello everyone, this is Neil Tu from Data Labs. I am in charge of Hadoop architecture at Line Corp. I construct and manage Hadoop clusters and their ecosystems, and supply a high availability, and high performance platform for the engineers and data analysts in our group. Today, the topic we are going to talk about is “Comprehensive Security for Hadoop”. Abstract Nowadays, Hadoop has become a popular platform for data storage, data analysis, reporting, and distributed calculations. Basically, Hadoop cluster is an open platform that supplies users with the required resources and HDFS capacity to execute queries. But as you (
)

More »

↧
Viewing all 52 articles
Browse latest View live