はじめに
API Meetup 18を聴講してきました。今回は久々のTech系！実際のサービスで使われているノウハウや苦労ポイントを聞けるのは非常に勉強になります。Apitoreを支える数々の技術は、ここでの技術情報がだいぶ参考になっています。今回は日本経済新聞、レコチョク、フォージビジョンさんの発表です。会場は大手町駅最寄りの日経ビルです。
発表
日経電子版を支える基盤API
日本経済新聞 髙安 伯武 さん
概要：先日、有料会員数が50万人を超え、多くのユーザーに使われる日経電子版のAPIのアーキテクチャ、開発、運用についてお話しします。
2015年に日経にJoin。最近はPythonとかAWSとか触ってる。日経電子版は有料会員50万人。6人で運用している。
日経電子版はAWS上で稼働。API Gatewayを設置し、すべてのAPIはここを通る。AWSのAPI Gatewayとは別に独自に設計している。APIはすべて認可が必要になっている。Djangoを使っている。Swagger UIを使っている。マイクロサービス化もしている。ElasticBeanstalkを使っている。サービスはDocker化しているし、ログはfluentdで送っている。独自にLog senderというパッケージを作っていて、githubで公開している。Githubを使っている。circleciを使っている。Alpine Linuxを利用。
Djangoを使っているので、このテンプレートを使って新しいAPIは簡単に作成＆リリースできる。マイクロサービスにしたから、APIごとに疎結合だから開発が進む。負荷の高いAPIだけスケールできる。APIごとに個別にデプロイできるので、変更が楽。BatchはRUNDECKを使っている。LOGはDockerオブジェクトからLog Senderでログ集約サーバーに送る。そこからBig QueryなりElastic Searchなりに送る。Elastic Searchには２ヶ月分くらいを格納し、kibanaで分析。
監視と通知について
- Jenkins
- StatusCake
- SENTRY
- New Relic
- slack
- pagerduty
- CloudWatch
Kibanaを活用。問題の分析に用いている。アプリケーションの名前の先頭にバージョンを入れておくことで、どのバージョンのどのアプリがエラーを起こしたかわかるようにしている。
画像処理系のSaaSを活用しようと考えている。顔の切り抜きとか、すかしの挿入とか。今後は自前にするか？SaaSを使うか？たぶんCase by Case。自前で作ったものを使っても、SaaS使っても、結果は同じ。どっちでもよいかなと。気持ちとしては、自分で作ったものが世界中で使われたら嬉しい。
※ここはホントそう思う。自前もSaaSも使えるものを使う世の中にした方が効率的だし楽しい。性能とコストの折り合いで使えるものを使えば良い。なので、仮に保有する技術についてこれ以上の改善はしなくとも、現在の性能で適切な価格設定であれば使いたいという人はいるんじゃないか？Apitoreはそういう技術の公開の場所になりたい。発表後に伺った所、考えもしなかったそうなので、日経で独自に立ち上げて販売するでもいいから、技術を公開していく流れは作っていきたい。
最後に、採用募集してるので、興味ある方はnikkeiのページを！
http://s.nikkei.com/saiyo
レコチョクのサービス群を支えるAPIたち(仮)
株式会社レコチョク 山本 耕琢 さん
概要：レコチョクはたくさんの音楽サービスを提供しており、その裏側では様々なAPIが動いています。各APIとマイクロサービスについてお話しします。
レコチョクの運用とエンハンス。業務ではコーディングはしない。レコチョクAPIは基本的にクローズドなAPI。ハッカソンでは一部公開する。
APIリストは以下の画像を参照。
※音源配布APIというものがきになる。適切な形で配信しているらしい。独自規格？
AWSに移行中。これまでちゃんと動いてきた実績があるが、技術的な負債もたくさんある。例えば、仕様書はWordをSVN管理。テストは手動でやっている。APIの利用状況は細かく把握できていない。AWS上のセキュリティも自信がない。AWSへのDeployも手動。swagger使いたい。AWS Athena使いたい。X-Ray使いたい。
※レコチョクの規模でこの状況というのはおもしろい。意外と運用できるもんなんだなと思ったし、リーンスタートアップだったらもっとギリギリのシステムでビジネス創っていっても良い気がしてきた。
Swaggerを利用した新規サービスWIZY開発の話(仮)
株式会社レコチョク 松木 佑徒 さん
概要：Swaggerを利用したAPIファーストな開発についてお話します。APIMeetup Tokyo #17のLTでお話しした内容から少し広げ、技術選定、APIとフロント(Web画面)をどのように開発しているかお話しします。
フロントサービスの開発担当。モバイルアプリ以外はなんでもできる。最近は機械学習もはじめた。レコチョク自体は、最近EggとかPlayPassとかリリースした。自身はWIZYを担当。WIZYはクラウドファンディングみたいなサービス。WIZYを支える技術は画像参照。
CodeGeneratorでPythonクライアントを生成。definitionで定義したものをjson化。JSON Web Tokenで認証。APIフレームワークはFlaskを使っている。現在は63個のAPIがある。
APIの仕様レビューをYAMLでやれるのは便利。変更がわかりやすくなった。Swaggerスペックさえ作れば、API開発とクライアント開発を同時に進行できる。仕様書の作成も簡単。Swaggerスペックがそのまま仕様書になるので。Swaggerスペックが同じであれば、APIのバージョンが上がっても動作保証できるので、blue-green deploymentで開発できるしとても便利。
新たにswagger 3.0がやってくる。移行はどうするか。。。
楽曲APIを提供する上での課題と今後の話(仮)
株式会社レコチョク 酒井 修平 さん
概要：API公開に至るには音楽業界特有の課題があります。その悩みや今後の展望をお話しします。
サーバーサイドエンジニア。APIを外部に公開したい。コンテンツを公開すれば、いろんな人がいじれてたのしそう。ハッカソンで公開してみたけど、、、ほとんど使われない。
インプットを画像にしたらおもしろい？ジャケ写、アーティスト写真などは持っている。
※ジャケ写と音楽データ持っているなら、それで深層学習したらおもしろそう。ジャケ写をシードに音楽を再現する。すると、例えばユーザーから写真を投稿してもらって、そこから音楽生成して配信する。風景にあった曲が自動生成されると熱い。技術的には出来そう。懇親会でレコチョクの福山さんと話したけど、おもしろいことができそうなのでやわらかハッカソン部の活動で巻き込んでいきたい。福山さんは前向きで乗り気だった。
Java EE 8でのREST API/Micro Servicesの実装 (20:40〜21:00)
フォージビジョン株式会社 相原 康伸 さん
概要：Java EE 8でのREST API/Micro Servicesの実装する場合のTips、実装例などをお話します。
開発車歴22年！ゲーム開発とか基幹系も。
JavaEE8で作るマイクロサービス。JAX-RS 2.1が入る。Reactive Client APIとNon Blocking I/Oがキモ。
※まだ仕様が発表されただけで、実装はないそう。しばらくはSpring安定かも。
JCache1.0とは・・・
アノテーションを加えるとキャッシュができるようになる。大規模システムには必須だそう。
JavaEE8をまとめると・・・
Yasson？を使うとよい。Json周りは安定している。マイクロサービス向けの機能を急ピッチで整備中。
おわりに
今回はAPI周りの開発環境について多く学べました。自動デプロイだとか、エラーからの復旧だとか、ログの収集だとか。Apitoreでも足りてない部分はあるので、参考になりました。最後はビールで乾杯！
