狠狠撸
Submit Search
楽天ポイントと厂辫谤颈苍驳
?
Download as PPTX, PDF
?
0 likes
?
905 views
S
Shuhei Shogen
Follow
JSUG勉強会 2018年その3 LT大会 https://jsug.doorkeeper.jp/events/73144 での資料です.
Read less
Read more
1 of 16
Download now
Download to read offline
More Related Content
楽天ポイントと厂辫谤颈苍驳
1.
楽天ポイントと厂辫谤颈苍驳 Apr.18. 2018 Shuhei Shogen Rakuten,
Inc.
2.
2 自己紹介 ? Name: 正元
修平(しょうげん しゅうへい) ? Job: エンジニア@楽天株式会社 ? 2015年新卒入社 ? 楽天スーパーポイントのAPI開発?運用に従事 ? Spring歴は約1年半 ? 最近はAndroid開発始めてます ? Hobby: アニメ,山登り,海外旅行
3.
3 楽天スーパーポイント 楽天ポイント お買いものパンダ登場編 –
Youtube (2018/4/12閲覧) https://www.youtube.com/watch?v=SdtCOdveesM ? 楽天の共通ポイントサービス
4.
4 楽天ポイントAPI ? フロントシステムからのAPIコールを受け,直接DBとやりとり ? ポイント残高を表示 ?
ポイントの付与/利用履歴を表示 ? ポイントの付与 ? ポイントの利用 ? 現行のAPI ? Servlet (Tomcat) ? フレームワークは使っていない ? レガシーでメンテがつらい??? 楽天市場 TOPページ(2018/4/12閲覧) https://www.rakuten.co.jp/
5.
5 APIプラットフォームのリニューアル ? 新しいAPIプラットフォーム ? 少し納期に余裕がある開発案件が来た ?
レガシーシステムつらいし,新しい環境でやってみよう ? Tech leadとしてプロジェクトに入ることに ? Spring Boot(Spring Web MVC)の採用 ? 他部署での実績 ? FWとしての将来性 ? 2018年4月現在,6APIが本番環境で稼働中
6.
6 新APIプラットフォームで実現したかったこと(抜粋) ? 新人エンジニアが入って来やすい ? 問い合わせ対応を楽にしたい ?
インフラ运用を楽にしたい(时间の都合で话しません) ? もちろん他にも???
7.
7 新APIプラットフォームで実現したかったこと(抜粋) ? 新人エンジニアが入って来やすい ? 問い合わせ対応を楽にしたい ?
インフラ运用を楽にしたい(时间の都合で话しません)
8.
8 新人が入って来やすい? ? メンバーの入れ替わりが多い ? 引き継ぎのコスト ?
システムとして,メンテナの交代に強いつくりにしたい ? スキルの高い人ばかりではない ? 「言われたことはなんとなくこなせる」レベルの人をどう扱うか ? 新しくプロジェクトに入った人が,すぐに開発を始められるとよい ? 目標:「Javaの経験はあるがSpring (Web FW)の経験がない人が,1ヶ月程度でAPIの開発?テストに入れる」
9.
9 どうしたか? ? プラットフォームのコア部分については,できるだけ自分で実装 ? 認証?ロギング?その他共通処理や,各レイヤの責務の規定,エラー設計 ?
開発者にビジネスロジックの開発に集中してもらいやすくする ? 負債化しないように,できるだけFW側のやり方に従う && 適宜レビューに出して見てもらう ? 足りない部分は,適宜ペアプログラミングやコードレビューで教育 ? ペアプロ:特にSpring特有の部分について手厚く ? コードレビュー:こちらはロジック/UTを中心に
10.
10 新APIプラットフォームで実現したかったこと(抜粋) ? 新人エンジニアが入って来やすい ? 問い合わせ対応を楽にしたい ?
インフラ运用を楽にしたい(时间の都合で话しません)
11.
11 問い合わせ対応を容易に ? 利用者(APIのクライアント,ひいてはエンドユーザ)からの問い合わせが多い ? 仕様の調査や,エラーの原因調査 ?
E.g., 「XXしたのになんでポイントついてないの?」 ? 現行APIではロジックが散逸 ? 調査に数日かかることも???
12.
12 どうしたか? ? ドキュメントの拡充 ? APIクライアント向け
/ 内部向け で内容を分ける ? 設計をキレイに保つ ? レイヤ化アーキテクチャ ? ソースコードを読む範囲を最小限に ? ログ設計 ? ストレスなくログを見たい ? 後述
13.
13 ログの設計 ? application.log: アプリ中でログに残したい情報を記録 ?
レベルはDEBUG, INFO, WARN, ERROR ? ERRORログが出力されるとアラート通知 ? request.log: APIへのリクエストを記録 ? Path, Body, Header, Hostnameなど,リクエストを特定できそうな情報すべて ? できるだけ確実にログに残るように,サーブレットフィルタの一番最初で記録 ? response.log: APIのレスポンスを記録 ? レスポンスのStatus code, Body, Header等に加え,レスポンスタイムなど ? レスポンス情報の取得後にAOPで記録 ? stdout.log: その他の標準出力をリダイレクト
14.
14 使ったOSS ? Spring Cloud
Sleuth ? https://cloud.spring.io/spring-cloud-sleuth/ ? もともとは分散トレーシングのためのもの ? ログを追う際,例えば,response.logのどの行がrequest.logのどの行に対応しているかを知りたい ? Spring Cloud SleuthのSpan IDを使うことで,リクエストに固有のIDを振ることができる ? logstash-logback-encoder ? https://github.com/logstash/logstash-logback-encoder ? 手軽にLogstash形式(JSON)のログを作れる(@timestampや@versionもつけてくれる) ? 拡張も比較的容易(logback.xmlにてencoderを指定) ? 生成したログをElasticsearchに送ってKibanaで可視化
15.
15 もっと良くしていきたいところ ? ドメイン駆動設計の導入 ? 現状はビジネスロジック部分がトランザクションスクリプト化している ?
ドメインに詳しくない開発者にも優しく ? 機能単位でのプラットフォーム分割 ? サービスレベルの低いAPIのリリースにサービスレベルの高いAPIが巻き込まれないようにする ? 将来のマイクロサービス化を見据える ? Spring 5 + Spring WebFlux (+ Kotlin)の導入 ? 同時大量アクセスに強くしたい ? サーバサイドKotlinやってみたい
16.
THANK YOU
Download