Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

マイクロサービスとOSSのおいしい関係

1,136 views

Published on

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

Published in: Technology
  • Be the first to comment

マイクロサービスとOSSのおいしい関係

  1. 1. マイクロサービスとOSSのおいしい関係 For Speee Cafe Meetup #07 5/23/2017 FiNC, inc. / Engineering Fumiya Shinozuka
  2. 2. 2 自己紹介 篠塚史弥 (@shinofumijp) サーバサイドエンジニア Rubyを主に使っている 最近はJavaエンジニア見習い 気になっているOSS Apache tinkerpop, JanusGraph
  3. 3. JanusGraph http://janusgraph.org/
  4. 4. Linux Foundationによるプロジェクト
  5. 5. 本番で使っているユーザ
  6. 6. 実績のないOSSも積極的に使っていきます(!)
  7. 7. 質問です
  8. 8. みなさん
  9. 9. OSS開発の経験はありますか?
  10. 10. 普段からバリバリ開発しているよって方
  11. 11. 本日はご清聴ありがとうございました
  12. 12. 興味はあるけどやり方がわからない、 時間が取れない方が多いと思います
  13. 13. OSS活動をするにもまずはOSS選定か ら
  14. 14. ということで
  15. 15. 今日はOSS選定に関する話をします (※Ruby寄り)
  16. 16. ただ
  17. 17. OSS選定もまずは使ってみてから
  18. 18. 日々の業務の中で様々な OSSを試す時間はとりづらい
  19. 19. 実践で試す機会はさらに稀
  20. 20. というわけで
  21. 21. 本番環境で、 影響範囲を小さく、 いいOSSを見つけられるように、 FiNCで実際に行っている方法を紹介します
  22. 22. OSSは品質が高いとは限らない
  23. 23. 例えば、 メンテナンスされていない APIが微妙 パフォーマンスが考慮されていない
  24. 24. どのOSSを選択するかは非常に大事
  25. 25. OSSを選択する観点は様々だが、 目的に合っていて、枯れている OSSを選ぶことが多い
  26. 26. ただ 枯れているからいいわけでもない 枯れていないけどいいOSSを選びたい
  27. 27. どうやっていいOSSを選択する?
  28. 28. ググる?
  29. 29. ソースを読む?
  30. 30. スター数、フォーク数を見る?
  31. 31. 実際に使ってみてわかることもある - 使いやすさ、運用しやすさ - 同時リクエスト - 負荷に応じた挙動
  32. 32. テストプロジェクトを立てる?
  33. 33. 本番で試せる方が早い
  34. 34. (ただし影響範囲は小さく)
  35. 35. そこで
  36. 36. マイクロサービスでOSSを試すことを おすすめします
  37. 37. FiNCではマイクロサービスを採用し、 マイクロサービスでOSSを試しています (参考) FiNCとマイクロサービス https://www.slideshare.net/fumiyashinoz uka/finc-52564251
  38. 38. マイクロサービス アプリケーションを複数の小さなサービスの 組み合わせで構築する設計、開発方法
  39. 39. (特徴はたくさんあるけど)
  40. 40. 疎結合 マイクロサービスでは、 原則WebAPIを通じて 各サービスがデータを共有する
  41. 41. 技術異質性 各サービスは それぞれに適した技術の利用が可能
  42. 42. 要は サービスが小さく別れているので、 影響範囲が小さく、様々な技術が試せます ということ
  43. 43. FiNCでの実例の紹介
  44. 44. まず前提
  45. 45. FiNCでの 1番コードベースの大きいRailsアプリの モデル数(≒テーブル数)
  46. 46. 1016
  47. 47. あまりやんちゃな変更したくない
  48. 48. 新しいアプリケーションのモデル数 たかだか20程度
  49. 49. 1016 vs 20
  50. 50. 影響範囲のレベルが違う
  51. 51. 前提おしまい
  52. 52. 例1. APIライブラリの選定
  53. 53. [背景] json_schemaの利用とそれに合わせたAPIライ ブラリの選定を行っていた 元々grape+rablというRubygemsを利用してい た
  54. 54. [問題] 規模の大きいアプリケーションに 最初から導入してるのはコストが大きかった ディレクトリの構成、リソースの粒度、オプション 設定、レスポンス構造のルールなど (参考) FiNCのWeb API開発事情 https://www.slideshare.net/fumiyashinozuk a/api-developmentinfinc-71710309
  55. 55. [対応] 新しく立ち上げたアプリケーションに導入し、 使い勝手と設定を試行錯誤し、 ベストプラクティスを見つけた後で、 他のアプリケーションに導入した
  56. 56. [おまけ] リクエストバリデーション、型変換周りが、 元々使用していたライブラリにはあったが、 新しいライブラリになく不便だったので PRを送ったらマージされた (参考) FiNCでのOSSとのつきあい方 https://www.slideshare.net/ota42y/fincoss
  57. 57. 業務としてOSS活動ができる!
  58. 58. 例2. 論理削除ライブラリの導入
  59. 59. 失敗談です
  60. 60. paranoiaというRubygemの利用 Githubスター数 1950, フォーク数 404 メンテナンスもされている テストプロジェクトで試してみても使いやすかった
  61. 61. メインアプリに投入(!)
  62. 62. …しかし
  63. 63. DB周りのRubygemは Railsのバージョンアップ時に壊れやすい 意図しない物理削除の挙動 本番のデータ構造ならではの不整合 論理削除って本当に必要だった、、、?
  64. 64. (ちゃんと見通してやれという話ではある)
  65. 65. [教訓] なるべく小さい範囲で試しに運用して だめなことがわかったら、影響範囲が広がる前に 消せることが大事
  66. 66. 冒頭で紹介したJanusGraphも マイクロサービスから使い始めました
  67. 67. その他にも、 非同期ライブラリ、 HTTPクライアント、 などなど大小諸々のOSSを マイクロサービスから試して比較選定しました
  68. 68. まとめ
  69. 69. 1. OSSの品質はピンきり 2. 実際に使わないとわからないこともある 3. 影響範囲が小さく試せる方法があると便利
  70. 70. 本日はご清聴ありがとうございました
  71. 71. FiNCではエンジニアを募集しています Railsアプリケーション開発, マイクロサービス, OSS, AI, GraphDB, 機械学習, Hadoopなどなど ご興味のある方はぜひご応募ください https://finc.com/recruit

×