Speee Cafe Meetup #7 (https://speee.connpass.com/event/56197/) で登壇した内容です。 業務中に効率よくOSSを試して、さらにはOSS活動をするためにマイクロサービスで影響範囲を小さく試す、という事例を紹介しました。

1. マイクロサービスとOSSのおいしい関係
For Speee Cafe Meetup #07
5/23/2017
FiNC, inc. / Engineering
Fumiya Shinozuka

2. 2
自己紹介
篠塚史弥 (@shinofumijp)
サーバサイドエンジニア
Rubyを主に使っている
最近はJavaエンジニア見習い
気になっているOSS
Apache tinkerpop, JanusGraph

3. JanusGraph
http://janusgraph.org/

5. Linux Foundationによるプロジェクト

6. 本番で使っているユーザ

8. 実績のないOSSも積極的に使っていきます(!)

9. 質問です

10. みなさん

11. OSS開発の経験はありますか？

12. 普段からバリバリ開発しているよって方

13. 本日はご清聴ありがとうございました

14. 興味はあるけどやり方がわからない、
時間が取れない方が多いと思います

15. OSS活動をするにもまずはOSS選定か
ら

16. ということで

17. 今日はOSS選定に関する話をします
(※Ruby寄り)

18. ただ

19. OSS選定もまずは使ってみてから

20. 日々の業務の中で様々な
OSSを試す時間はとりづらい

21. 実践で試す機会はさらに稀

22. というわけで

23. 本番環境で、
影響範囲を小さく、
いいOSSを見つけられるように、
FiNCで実際に行っている方法を紹介します

24. OSSは品質が高いとは限らない

25. 例えば、
メンテナンスされていない
APIが微妙
パフォーマンスが考慮されていない

26. どのOSSを選択するかは非常に大事

27. OSSを選択する観点は様々だが、
目的に合っていて、枯れている
OSSを選ぶことが多い

28. ただ
枯れているからいいわけでもない
枯れていないけどいいOSSを選びたい

29. どうやっていいOSSを選択する？

30. ググる?

31. ソースを読む？

32. スター数、フォーク数を見る?

33. 実際に使ってみてわかることもある
- 使いやすさ、運用しやすさ
- 同時リクエスト
- 負荷に応じた挙動

34. テストプロジェクトを立てる?

35. 本番で試せる方が早い

36. (ただし影響範囲は小さく)

37. そこで

38. マイクロサービスでOSSを試すことを
おすすめします

39. FiNCではマイクロサービスを採用し、
マイクロサービスでOSSを試しています
(参考)
FiNCとマイクロサービス
https://www.slideshare.net/fumiyashinoz
uka/finc-52564251

40. マイクロサービス
アプリケーションを複数の小さなサービスの
組み合わせで構築する設計、開発方法

41. (特徴はたくさんあるけど)

42. 疎結合
マイクロサービスでは、
原則WebAPIを通じて
各サービスがデータを共有する

43. 技術異質性
各サービスは
それぞれに適した技術の利用が可能

44. 要は
サービスが小さく別れているので、
影響範囲が小さく、様々な技術が試せます
ということ

45. FiNCでの実例の紹介

46. まず前提

47. FiNCでの
1番コードベースの大きいRailsアプリの
モデル数(≒テーブル数)

48. 1016

49. あまりやんちゃな変更したくない

50. 新しいアプリケーションのモデル数
たかだか20程度

51. 1016 vs 20

52. 影響範囲のレベルが違う

53. 前提おしまい

54. 例1. APIライブラリの選定

55. [背景]
json_schemaの利用とそれに合わせたAPIライ
ブラリの選定を行っていた
元々grape+rablというRubygemsを利用してい
た

56. [問題]
規模の大きいアプリケーションに
最初から導入してるのはコストが大きかった
ディレクトリの構成、リソースの粒度、オプション
設定、レスポンス構造のルールなど
(参考)
FiNCのWeb API開発事情
https://www.slideshare.net/fumiyashinozuk
a/api-developmentinfinc-71710309

57. [対応]
新しく立ち上げたアプリケーションに導入し、
使い勝手と設定を試行錯誤し、
ベストプラクティスを見つけた後で、
他のアプリケーションに導入した

58. [おまけ]
リクエストバリデーション、型変換周りが、
元々使用していたライブラリにはあったが、
新しいライブラリになく不便だったので
PRを送ったらマージされた
(参考)
FiNCでのOSSとのつきあい方
https://www.slideshare.net/ota42y/fincoss

59. 業務としてOSS活動ができる！

60. 例2. 論理削除ライブラリの導入

61. 失敗談です

62. paranoiaというRubygemの利用
Githubスター数 1950, フォーク数 404
メンテナンスもされている
テストプロジェクトで試してみても使いやすかった

63. メインアプリに投入(!)

64. …しかし

65. DB周りのRubygemは
Railsのバージョンアップ時に壊れやすい
意図しない物理削除の挙動
本番のデータ構造ならではの不整合
論理削除って本当に必要だった、、、？

66. (ちゃんと見通してやれという話ではある)

67. [教訓]
なるべく小さい範囲で試しに運用して
だめなことがわかったら、影響範囲が広がる前に
消せることが大事

68. 冒頭で紹介したJanusGraphも
マイクロサービスから使い始めました

69. その他にも、
非同期ライブラリ、
HTTPクライアント、
などなど大小諸々のOSSを
マイクロサービスから試して比較選定しました

70. まとめ

71. 1. OSSの品質はピンきり
2. 実際に使わないとわからないこともある
3. 影響範囲が小さく試せる方法があると便利

72. 本日はご清聴ありがとうございました

73. FiNCではエンジニアを募集しています
Railsアプリケーション開発, マイクロサービス,
OSS, AI, GraphDB, 機械学習, Hadoopなどなど
ご興味のある方はぜひご応募ください
https://finc.com/recruit