Architecture Sustaining LINE Sticker services
•Download as PPTX, PDF•
6 likes•1,801 views
Masahiro Ide (LINE Corporation) LINE Vietnam Opening Day, March 31st 2018
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Architecture Sustaining LINE Sticker services
Similar to Architecture Sustaining LINE Sticker services (20)
More from LINE Corporation
More from LINE Corporation (20)
Recently uploaded
Recently uploaded (20)
Architecture Sustaining LINE Sticker services
- 1. Architecture Sustaining LINE Sticker Services Masahiro IDE, LINE CORP
- 2. About me • Masahiro Ide • Software Engineer of LINE server development • Especially StickerShop backend server • Joined: Oct, 2015 • Contribute to Armeria • Our open sourced asynchronous RPC/REST library • https://github.com/line/armeria
- 3. Agenda • Sticker Shop Server • History • Our Architecture • Implementations
- 4. What is Sticker Shop?
- 5. Sticker Shop … in 2015 One of the biggest monolithic Java application in LINE • Purchasing, Serving, Ranking stickers in 1 app • Many pains, troubles • Takes more than 3 hours to restart app
- 6. Sticker Shop in 2018 Now shift to microservice way for scalability • 1 million stickers • 30 services • Purchasing, Serving, Ranking stickers, etc. • 70K requests/sec in peek time
- 7. StickerShop Architecture Overview (Simplified) Central Dogma – Configuration Repository Service Talk server ElasticSearch Client ReverseProxy Thrift/HTTP2 Thrift/HTTP2 Redis MySQL Sticker capability server Shop server Search FE Thrift/HTTP2
- 8. Implementation • What we need is… • Performance • Prepared to faults • Observability • Stable feature rollout
- 9. Central Dogma • Repository service for textual configurations • JSON, YAML, XML … • Highly available • multi-master, eventually consistency • Version controlled • https://line.github.io/centraldogma/
- 10. Armeria - Our RPC layer • Asynchronous RPC/REST library • built on top of Java 8, Netty, HTTP/2, Thrift and gRPC • Take care common functionality for microservice 1. Load balancing 2. Circuit Breaker / Retry / Throttling 3. Tracing (Zipkin) / Monitoring integration • etc. https://line.github.io/armeria/
- 11. 1. Client-side load balancing • No proxy load balancers • Proxy would be inefficient when considering request heavy services • CentralDogma as a service discovery • All services register a name and a list of machines in CentralDogma • All clients monitor CentralDogma and balance requests across machines LB Client Server Client Server Server Proxy load balancing
- 12. 1. Client-side load balancing • No proxy load balancers • Proxy would be inefficient when considering request heavy services • CentralDogma as a service discovery • All services register a name and a list of machines in CentralDogma • All clients monitor CentralDogma and balance requests across machines Central Dogma Client Server Client Server Server
- 13. 2. Circuit Breaker - Avoid cascading failure • Server die suddenly • e.g. Hardware failure • Upstream cannot proceed part of requests, in worst case • Blocks all of application thread • LINE die Service A Service C Service B
- 14. 2. Circuit Breaker - Avoid cascading failure • Circuit Breaker pattern* 1. Monitors failures 2. Return error immediately without RPC once the failures reach a threshold Service A Service C Service B CircuitBreaker CircuitBreaker * https://martinfowler.com/bliki/CircuitBreaker.html
- 15. 3. Tracing • Hard to point out the slowness/bug in microservice • No one provides complete picture of system performance Talk server ElasticSearch Reverse Proxy Redis MySQL Shop server Search FE T=start T=end
- 16. 3. Tracing • Solution: Distributed tracing with Zipkin
- 17. Rollout features using CentralDogma (CD) • Rollout to production within 10 minutes of being changed • Deploy a YAML file to all our production servers via CD • Record changes in CD commit log
- 18. Rollout features using CentralDogma • Rollout to production within 10 minutes of being changed • Deploy a YAML file to all our production servers via CD • Record changes in CD commit log 30%CacheV2 rollout: Central Dogma Service Service Service commit YAMLPull & Reload config Developer
- 19. Conclusion • Our system is built on top of our OSSs • Armeria, CentralDogma, and more • … are still evolving • Trouble may happen • Make a well trouble-prepared system • Let's do a smooth release
- 20. Q & A
Editor's Notes
- こんにちは、LINEのIde masahiroです。これからの20分間は我々LINEのサービスの１つであるsticker、それを支えているアーキテクチャや仕組み、その概要をお話しできればと思います。よろしくお願いいたします。まず最初に(次のページ)
- 私はLINEでサーバサイドエンジニアをしています。特にメッセージングやスタンプなどを中心に開発を行っています。2015年の10月に入社したのでおよそ2.5年ほど経ちましたが、LINEでは日本語や韓国語、英語などの言葉の壁、サービスの部署の壁などは特別なく、自由な開発を行えていると思っています。それでは、(次のページ)
- 本題に移っていきましょう。これが本日のアジェンダになります。まず、最初にこの発表で扱うサービスであるstickershop、そのサービスだったりアーキテクチャの概要を紹介します。そのあとに、それを支えるRPC layerの紹介、そしてサービスのリリースを支えるopsの紹介をします。それでは最初の内容に移っていきましょう。
- LINEでも良いですし、他のメッセージングアプリでも構いません。Stickerを作ったことがある方はいますか？もしくはstickerを買ったこと? あるいは送ったこと？送ることは結構な人数がいますかね？ありがとうございます。そうです。ラフに言うと、stickerに関連する、作る、買う、送る、この3つの仕組み提供しています。(厳密には送る部分はmessagingに関わるserviceが担当しますが、概ね間違っていないと思う) そしてアプリケーションの規模、サービスの規模を表す１つの例として、2015年に我々は(次のページ)
- サービスが発展して行く中でいくつかの問題を抱えていました。ほとんどの原因は巨大なmonolithic applicationであったことに起因します。それにより、
- それでは2018年に戻ってきましょう。現在のstickershopは、この３つの数字で表せると思います。これは大体の数字ですが、2018年現在でおおよそ1 million productが実際のstickerとして皆さんの手元から相手のchatに届いています。そして、おおよそ3つの機能を提供するために30以上のmicroserviceによって作る、売る、送るという機能は作られてます。最後に、サービスとして処理するrequestの量ですが、peek of peekで話しますと大体70K req/sec程度が一番忙しい時にはあったりするという規模感になっています。では、それを実現するアーキテクチャはどのようになっているでしょうか？(次のページ)
- この図はstickershopのアーキテクチャを表しています。先ほど30以上のサービスから構成されていると言いましたが、ここでは代表して数個のserviceが登場しています。青い線で書かれているように、LINE clientから送られてきたrequestはreverse proxyを通じてbackend serverに機能に応じてrequestを投げていき、storageまでアクセスされます。それぞれのサービスはお互いに通信しながらサービスを提供するので、大体メッシュ状のような形状になっていて、CentralDogmaと呼ばれるconfiugrationを一箇所で管理するserviceと繋がっています。そして、LINE ClientとserverはThrift over http2のrequestで通信が行われています。同様に、サーバ間の通信は大体Thrift over http2で行われています。
- では、我々はこのアーキテクチャをどのように支えているのでしょうか？今日はこの４つの点で話してみたいと思います。まず初めにサービスのインフラとして(次のページ)
- まず最初に説明したいのは、CentralDogmaと呼ばれるconfigurationを一箇所で管理するserviceです。サービスをrolloutしたりconfigurationを
- そして、これまで説明してきたサービスにおいて、通信は、それを支えるRPC layer、Armeriaと呼ばれるserver/client libraryによって提供されています。 Armeriaは我々がopen sourceにしたAsynchronous RPC/REST libraryです。Eventloop baseのnetwork libraryであるnettyをベースにしており、その上でHTTP1, HTTP2, そしてThriftやgRPCなどRPC機能を提供しています。一番下に書いてあるURLでdocumentationやソースコードは公開されていますのでもし興味がありましたらぜひ試してください。 このArmeriaでは、先ほど説明したようなmicroserviceを実現する上で必要な機能も合わせて提供してくれています。代表的な機能としてはLoad balancingの機能や、リクエストが失敗した時、サービスに障害があった時に有用なthrottling, request limittingの機能、また、モニタリングやサービス全体のトレースを行うためのintegrationがあります。
- 古典的なサービスではclientとserverの間の間にproxyを置いて、requestをservingしていたと思います。しかし、storage serviceのようなrequestの多いサービスではLBを経由するコストは無視できません。我々は(次のページ)
- CDを用いたclient side loadbalancingの仕組みを作り、サーバサイドのinter connectionのrequestを効率化しています。
- そして、次に説明したいのはcircuit breakerという仕組みです。みなさんご存知の通り、applicationは様々な理由によって突然死にます。そして、最悪の場合、その障害はupstreamサーバのrequestをブロックし、application serverのthreadをブロックします。そして最終的にはその影響はサービス全体に波及してLINEが死にます。そのような状況を防ぐために(次のページ)
- Circuit Breakerという仕組みを利用してサービスの影響を波及させないようにしています。仕組みについては非常によく知られています。このURLを参考にしていただければと思います。 (次のページ)
- 3つめに紹介したいのはtracingについてです。Microservice上で開発する上で一番大変なことは何か問題が発生した時にそれがどこで発生したかを正しく理解することです。 (次のページ)
- (次のページ)
- 最後に紹介したいのは、どのようにfeatureのrolloutをしているかについてです。 All of our servers run a background thread called the “CentralDogma watcher” which constantly watches the CentralDogma_config.json copy on memory, reloading it when it changes. This allows CentralDogma to reload without interruption to the server.
- 最後に紹介したいのは、どのようにfeatureのrolloutをしているかについてです。 All of our servers run a background thread called the “CentralDogma watcher” which constantly watches the CentralDogma_config.json copy on memory, reloading it when it changes. This allows CentralDogma to reload without interruption to the server.
- ここまで、Armeria, CentralDogma、いくつかのLINE, StickerShopを支える仕組みについて紹介してきました。