Slide 1

Slide 1 text

MF KESSAI が、技術的挑戦を繰り返しながら サービス価値と開発のIKIOI を上げ続けてる話 MF KESSAI 株式会社 CTO (兼SRE ) 篠原 祐貴(@shinofara )

Slide 2

Slide 2 text

Index

Slide 3

Slide 3 text

本日お話する事 MF KESSAI と登壇者について 創業からこれまでのサマリ これまでに発生したIssue とAction と反省 開発を支える文化とIKIOI を大事にする文化 採用に関する考え方と案内 おわり 1. 2. 3. 4. 5. 6.

Slide 4

Slide 4 text

MF KESSAIと登壇者情報

Slide 5

Slide 5 text

MF KESSAI という会社について corp.moneyforward.com マネーフォワード、子会 社「MF KESSAI」を設 立 手間もリスクもゼロ 、企業間後払い決済サー ビスを提供開始 中小企業の資金繰りの課題を解決、業務 効率化の一歩先へ お金のプラットフォ ームを提供する株式会社マネーフォワー ド(本社:東京都港区、代表取締役社長 CEO:辻庸介、以下「当社」)は、2017 年3月16日付で当社の1…… MF KESSAI 株式会社 2017 年03 月設立 株式会社マネーフォワード100% 子会社 大手町ビル内Finolab にオフィスを構える 初期は社員4名とインターン2名でスタート corp.mfkessai.co.jp MF KESSAI株式会社を設 立しました | MF KESSAI 株式会社 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 のコーポレートサイトです。企業情報、 ニュース、採用情報など様々な情報を掲 載しています。… corp.mfkessai.co.jp MF KESSAI株式会社 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 のコーポレートサイトです。企業情報、 ニュース、採用情報など様々な情報を掲 載しています。… https://corp.mfkessai.co.jp https://corp.mfkessai.co.jp/press/2017/06/mf- kessai 株式会社を設立しました/ https://corp.moneyforward.com/news/release/serv ice/20170620- mf- kessai/

Slide 6

Slide 6 text

MF KESSAI というサービスについて MF KESSAI サービス紹介動画 YouTube カンタンであんしんな企業間請求代行サービス「MF KESSAI 」

Slide 7

Slide 7 text

登壇者(私)について 篠原 祐貴(@shinofara ) 1987 年1 月(32 歳) 現在の役割 CTO SRE Gopher (最近減りました) 入社時期 マネーフォワードに2016 年12 月 MF KESSAI は2017 年1 月頃から参加 よく使うエディタ Emacs( エディタではない) Goland Visual Studio Code lapras.com 篠原 祐貴さんのLAPRAS ページ LAPRASは、すぐれた機械学習技術とクロ ーリング技術を使い、インターネット上 でオープンになっている情報を集め、 「プロフィール」を自動生成します。… https://lapras.com/public/K6CCUJS

Slide 8

Slide 8 text

技術系の登壇履歴 マネーフォワードの子会社MF KESSAIが選択したアーキテクチャ Speaker Deck GoとGCPとkubernetesを使った MF KESSAIの歴史 Speaker Deck 酔いどれGCPUG 2018/03/02 / PubSubとGAE/FEでサクッと大量にPDF生成出来るようにしたお話 Speaker Deck https://speakerdeck.com/shinofara/manehuowadofalsezi- hui- she- mf- kessaigaxuan- ze- sitaakitekutiya https://speakerdeck.com/shinofara/gotogcptokuberneteswoshi- tuta- mf- kessaifalseli- shi https://speakerdeck.com/shinofara/fedesakututoda- liang- nipdfsheng- cheng- chu- lai- ruyounisitaohua

Slide 9

Slide 9 text

創業からこれまでのサマリ

Slide 10

Slide 10 text

History 2017 年 03 月 MF KESSAI 株式会社創業 05 月 Go で開発した社内サービスリリース 11 月 導入企業向けWEB &API V1 リリース、また社内サービスのドメインロジックをgRPC で独立させてリリース 2018 PubSub とGAE で大量にPDF 生成する為のPDF サービスリリース 消込サービス稼働開始 Nuxt,js で開発した社内管理ツールが複数誕生 データ解析・分析や、機械学習を用いた審査モデル構築に特化したチーム誕生 2019 08/23 Money Forward Developer's Stories XX/XX API V2 リリース

Slide 11

Slide 11 text

MF KESSAI が0から考え選択した技術 tech.mfkessai.co.jp 新会社「MF KESSAI」は どのような技術・インフ ラ・体制で開発している のか | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… マネーフォワードの子会社MF KESSAIが選択したアーキテクチャ Speaker Deck Go Docker Kubernetes (k8s ) Google Cloud Platform (GCP ) それは結果的にマネーフォワードと全く異なるアーキテクチャ https://speakerdeck.com/shinofara/manehuowadofalsezi- hui- she- mf- kessaigaxuan- ze- sitaakitekutiya https://tech.mfkessai.co.jp/2017/07/1/

Slide 12

Slide 12 text

アプリケーションの種類 4 4 4 6 6 6 8 8 8 0 0 0 2 2 2 2 2 2 0 0 0 4 4 4 6 6 6 1 1 1 6 6 6 24 24 24 0 0 0 6 6 6 12 12 12 0 0 0 2 2 2 1 1 1 1 1 1 2 2 2 3 3 3 Go Container Nuxt Container Python Container Other Container Cloud Functions GAE/Fe(Go Container) Firebase Hosting 2017 2018 2019 0 10 20 30 数字で見るMF KESSAI の開発 ものづくりメンバーの割合 Backend Backend Backend: 46.2 % : 46.2 % : 46.2 % Frontend Frontend Frontend: 7.7 % : 7.7 % : 7.7 % SRE SRE SRE: 15.4 % : 15.4 % : 15.4 % Designeer Designeer Designeer: 15.4 % : 15.4 % : 15.4 % Data Engineer Data Engineer Data Engineer: 7.7 % : 7.7 % : 7.7 % Data Scientist Data Scientist Data Scientist: 7.7 % : 7.7 % : 7.7 %

Slide 13

Slide 13 text

Dev(Sec)Ops に関わる技術で見るMF KESSAI の歴史 2017 年 Sentry (Error Tracking ) CircleCI (CI / CD ) Github (git ) Jenkins on GKE (CI / CD ) Stackdriver(Monitoring/Logging) Datadog (Monitoring ) 2018 Cloud Builder (CD ) Spinnaker (CD ) Stackdriver Profiler 2019 Opencensus Trace / Metrics Vaddy Github Actions(CI / CD)

Slide 14

Slide 14 text

日々利用するツールで見るMF KESSAI の歴史 2017 年 Docbase Slack Github Asana Gsuite 2018 Zapier Zendesk Salesforce 2019 Miro

Slide 15

Slide 15 text

これまでに発生したIssueとActionと反省

Slide 16

Slide 16 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 17

Slide 17 text

今回お話しない事 プログラミングの話など技術に踏み込むお話は今回はSKIP アーキテクチャの細かい選定理由やロジックなどもSKIP 1. 2.

Slide 18

Slide 18 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 19

Slide 19 text

gRPC 導入とService Discovery Admin(Go ) Cloud SQL Service Ingress Google Kubernetes Cluster 創業時は社内ツールという事もあり、とてもシンプルな構成 ※ この頃はGKE はとても無駄な使い方ですね

Slide 20

Slide 20 text

gRPC 導入とService Discovery Service Ingress 2017 年後半にWEB/API リリース時の構成 Service Ingress WEB(Go) Cloud SQL Service gRPC(Go) REST API(Go) Service Ingress Admin(Go)

Slide 21

Slide 21 text

gRPC 導入とService Discovery k8s Service Ingress gRPC(Go) Pod をデプロイする度に、クライアントでLost Connection 発生 k8s Service Ingress WEB(Go) Cloud SQL Service gRPC(Go) REST API(Go) k8s Service Ingress Admin(Go) デプロイ!! Connection Lost

Slide 22

Slide 22 text

発生した理由 Kubernetes Service はPod の経路情報を返す仕組みである事 gRPC はコネクションを使いまわすこと Pod はデプロイやスケール毎に生死を繰り返しIP が変動し続ける事 deeeet.com Kubernetes上でgRPCサ ービスを動かす https://deeeet.com/writing/2018/03/30/kubernetes - grpc/

Slide 23

Slide 23 text

解決するにはどうしたらいいのか Client Side LB Proxy LB Sidecar(Envoy/Linkerd/Istio と行ったService Mesh) 経路が変わるのであれば何かしらの手段で経路選択などを行えれば良い 2017 年時点で採用できた手法は、公式ブログ書かれている選択しになります。 https://grpc.io/blog/loadbalancing/

Slide 24

Slide 24 text

gRPC 導入とService Discovery Sidecar にService Mesh のEnvoy を追加して、gRPC とのProxy として利用 WEB(Go) Service Envoy WEB(Go) Envoy WEB(Go) Envoy

Slide 25

Slide 25 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 26

Slide 26 text

Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 2018 年初期 MF KESSAI はGo でHTML レンダリングをするサービスが2つ存在した Service Ingress WEB(Go) gRPC(Go) Service Ingress Admin(Go)

Slide 27

Slide 27 text

Go のhtml/template でHTML レンダリングして出力 Typescript でVue.js のクライアントサイド実装 ※ この辺りを詳しく知りたい方はブログを見てみてください フロント部分は何で何していたのか tech.mfkessai.co.jp MF KESSAIの現在のフロ ントエンド環境について | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… https://tech.mfkessai.co.jp/2018/10 /frontend/

Slide 28

Slide 28 text

現在では2 つのNuxt サービスが稼働しています。 Nuxt.js Nuxt.js GraphQL(Go) HTTP gRPC Cloud SQL Cloud SQL gRPC WEB gRPC(Go) Service A Service B tech.mfkessai.co.jp Go + gqlgenを使った GraphQLアプリケーショ ンサーバーの実装 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… ※GraphQL に関してはこちらのブログを参照 https://tech.mfkessai.co.jp/2018/08 /go- gqlgen- graphql/

Slide 29

Slide 29 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 30

Slide 30 text

どのような課題が存在したか 創業初期は社内ツールとシンプルな請求書生成バッチのみ wkhtmltopdf でPDF を発行して居たため柔軟にデザインを組み立て辛かった バッチは定期的に実行され、直列にPDF を作成していた 導入企業向けにWEB/API をリリースするタイミングから、請求書を発行する 日時を指定できる状態となる為、特定の日時にスパイクする事で、処理時間 がかかりすぎる懸念が生まれる

Slide 31

Slide 31 text

数値は公開する事はできませんが、 月末月初にスパイクする請求書発行の動き

Slide 32

Slide 32 text

課題に対して選択した施策たち tech.mfkessai.co.jp ChromeでPDF作り始め て十数か月の日々が流れ た | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… 酔いどれGCPUG 2018/03/02 / PubSubとGAE/FEでサクッと大量にPDF生成出来るようにしたお話 Speaker Deck Chrome Headless を使う PubSub + GAE/Fe で並列化 https://tech.mfkessai.co.jp/2018/08/chrome/ https://speakerdeck.com/shinofara/fedesakututoda- liang- nipdfsheng- cheng- chu- lai- ruyounisitaohua

Slide 33

Slide 33 text

結果どうだったか Pros 並列数が増え続けても時間内で発行完了し続けられる状態に 軽いPDF も重いPDF も関係無く発行可能 処理途中に再実行により解決可能な問題が発生した場合は自動でリトライ実 行され解決 Chrome を使うことで請求書デザインの選択肢が広がった Cons 使われない夜中もFlexInstance のコストが掛かる デプロイが徐々に重くなり今では15min デプロイタイムアウトに苦しむ日々もあった スケール速度の問題 Chrome の起動周りに多少のコストが掛かる Cons はあるがPros の恩恵は大きい。がDX はよろしくないといった状況でした。 後半のスライドで更に解決編があります。

Slide 34

Slide 34 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 35

Slide 35 text

様々なクラウドサービスを利用することで 秘密情報管理・配布が辛い Kubernetes はkubernetes secret Cloud Functions / GAE はDeploy 時に一緒にデプロイ Run は、KMS で暗号化したファイルを起動時に取得して複合 全ての管理はCloud Repository で、デプロイ時に良しなにしている

Slide 36

Slide 36 text

新しい秘密情報管理・配布の仕組みに求めた要件 各アプリケーション( コンテナや1function 単位) で認証を行う事ができる GCP のService Account 毎に取得できる情報を制限できる 開発者毎にアクセスできる情報レベルや、参照権限、書き込み権限をある程 度柔軟にできる。 GCP マネージド or Container レベルで運用できること 秘密情報のバージョン管理ができること

Slide 37

Slide 37 text

Hashicorp Vault を利用する事にした理由 サービス毎にServiceAccount を作成して、SA Key を使って認証が可能 ServiceAccount 毎には取得可能な秘密情報だけRead 権限を付ける KMS を使って暗号化される CLI やUI から秘密情報の追加や更新が可能 GCP 上で動かすために必要な情報は公式ドキュメントに存在している cloud.google.com シークレット管理のため に Compute Engine で Vault を使用する | ソリ ューション | Google Cloud https://cloud.google.com/solutions/using- vault- for- secret- management? hl=ja

Slide 38

Slide 38 text

様々なクラウドサービスを利用することで 秘密情報管理・配布が辛い GAE Vault(Run) Pod GCS KMS Functions Service AccountのJWT Tokenを使って クライアント認証を行う Cloud Run でHashicorp Vault を動かして秘密情報管理サービスとして立ち上げてみた

Slide 39

Slide 39 text

結果どうだったか Pros アプリケーション起動時にしかリクエストが来ない事もあり、実行回数少な め=Run の運用コストは低い Dockerfile とアプリケーションだけあればあとはgcloud コマンドでデプロイ できるシンプルさ Cons Run のスピンアップに多少コストがかかる 起動時にVault を利用可能状態にする処理(Auto Unseal )が失敗する条件があることにより、事故につながる Vault が起動しないと他のアプリケーションの起動時に取得する秘密情報取得 に失敗してしまう。 そこで改めて、Kubernetes で運用する事に決意した

Slide 40

Slide 40 text

様々なクラウドサービスを利用することで 秘密情報管理・配布が辛い GAE Vault(Pod) Pod GCS KMS Functions Service AccountのJWT Tokenを使って クライアント認証を行う 基本的な構成は変わらずCloud Run からKubernetes に移行 Ingress / Service

Slide 41

Slide 41 text

tech.mfkessai.co.jp Cloud Native時代のMF KESSAIが選択した秘密情 報管理と配布について | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… 書ききれないので、ブログに公開しました。 結果どうだったか https://tech.mfkessai.co.jp/2019/08/next_secret_management/

Slide 42

Slide 42 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 43

Slide 43 text

そもそもObservability (可観測性)に課題あるよね このRPC どこからいつ呼ばれているのか このリクエストパフォーマンス悪いけど、どこがネックなのか このリクエスト走る時、このサービスリソース使いすぎてるけど何が原因? この処理って何回実行されていて、平均的なレイテンシとか、Max はどれく らい?

Slide 44

Slide 44 text

Observability とはなにか www.infoq.com 可観測性とマイクロサー ビス Zach Jory氏は、スケールアップが可能で 管理の容易なクラウドネイティブアプリ ケーションの構築を可能にする上で、マ イクロサービスとサービスメッシュ実装 の可観測性がいかに必要であるかを論じ た記事を書いた。氏の主張は、我々が過 去数ヶ月にわたって公開した多数の記事 や、その中で取り上げてきたインタビュ ーの内容にも通じるものがある。… 可観測性とは、データの顕在化と情報へのアクセスの容易化です。通信がフェールした時、期待通りに実 行されなかった時、あるいは期待しない場面で発生した時、これが重要になります。サービス相互の稼働 時のインタラクションは監視し、管理し、コントロールする必要があるのですが、そのためにはまず、可 観測性と、マイクロサービスアーキテクチャの振る舞いを理解できることが必要なのです。

Slide 45

Slide 45 text

tech.mfkessai.co.jp OpenCensus meetup vol.1参加レポート | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… どのように向き合ったか OpenCensus Meetup に参加 アプリケーションにOpenCensus を導入 Trace(Stackdriver / Jaeger) Stats(Stackdriver / Datadog) Stackdriver Profiler を導入 https://tech.mfkessai.co.jp/2019/04/ opencensus- meetup- report/

Slide 46

Slide 46 text

PDF 処理が同時間に大量に発生した時 平均値を大幅に超え20- 40 秒も処理時間がかかってることが判明

Slide 47

Slide 47 text

PDF 処理が同時間に大量に発生した時 正常な場合はChrome 起動前にセマフォでロックしてる箇所が0.004ms ほど

Slide 48

Slide 48 text

PDF 処理が同時間に大量に発生した時 高負荷な場合はロック解除されるまで14737ms もかかってる場合も

Slide 49

Slide 49 text

結果どうだったか GAE/Flex で捌けているが実はパフォーマンスが良くなかったことに気づけた パフォーマンスが良くない原因も特定が容易になった 注:Span を追加する必要あり

Slide 50

Slide 50 text

今回この場でお話する予定の 技術的な転換イベントリスト gRPC 導入とService Discovery(Envoy) Go でフロントエンド部分の開発で戦いそしてNuxt.js を採用 請求書作成を同期的直列から非同期並列化 秘密情報管理・配布のツラミとVault への期待 Observability( 可観測性) に課題があり調査が難しい 続請求書問題!GAE/Flex のつらさとCloudRun への希望 1. 2. 3. 4. 5. 6.

Slide 51

Slide 51 text

GAE/FE を使ってることでPDF サービスに影響があったか デプロイに毎回平均13 分 デプロイタイムアウトに苦しむ日々もあった サービスの要件に合わないスケール速度 使われない夜中もFlexI nstance のコストがかかってる 前提として弊社でのPDF サービスが、GAE/Fe の特性にマッチしていないとい う背景もありますが、事象としてあげると

Slide 52

Slide 52 text

GAE とRun のデプロイ速度比較(MFKESSAI の場合) CD 環境がCircleCI から、Cloud Builder に変更になった事も影響はしていると思いますが、大幅な改善があり

Slide 53

Slide 53 text

処理単位の実行時間 GAE とRun は初期は同じ数秒台、PubSub は成功が続くと徐々にPost 件数を増やしてくるため、 GAE ではスケールまで徐々に処理が長くなる傾向、ただしスケール後は数十インスタンスで 処理することになるため、比較的早くなる。 一方でRun は安定的に処理を実施 0k 5k 10k 15k 20k Cloud Run App Engine

Slide 54

Slide 54 text

開発を支える文化とIKIOIを大事にする文化

Slide 55

Slide 55 text

初期の開発文化 社内のmarkdown wiki にはこうかかれていました。

Slide 56

Slide 56 text

変わりゆく開発文化 tech.mfkessai.co.jp みんなで寄ってたかって タスクを潰している話 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… tech.mfkessai.co.jp デザインスプリントを短 縮してやってみた | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… tech.mfkessai.co.jp MF KESSAIの開発文化 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… https://tech.mfkessai.co.jp/2018/04/1/ https://tech.mfkessai.co.jp/2018/10/flow/ https://tech.mfkessai.co.jp/2018/06/design- sprint/

Slide 57

Slide 57 text

開発組織がユーザに提供する価値の最大化を行い続けるために、 現在のパフォーマンスの可視化と将来向上し続ける為の指標とし「IKIOI 」が生まれました。 そして生まれた開発チームの生産性指標「IKIOI 」

Slide 58

Slide 58 text

IKIOI とはどんな指標か tech.mfkessai.co.jp DevOpsパフォーマンス 改善開発合宿 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… https://tech.mfkessai.co.jp/2019/06/ikioi/

Slide 59

Slide 59 text

8 8 8 9 9 9 13 13 13 16 16 16 16 16 16 10 10 10 17 17 17 16 16 16 16 16 16 14 14 14 18 18 18 20 20 20 16 16 16 24 24 24 7 7 7 33 33 33 38 38 38 41 41 41 36 36 36 17 17 17 33 33 33 23 23 23 32 32 32 21 21 21 30 30 30 35 35 35 28 28 28 22 22 22 26 26 26 4.2 4.2 4.24.7 4.7 4.76.7 6.7 6.7 11.4 11.4 11.4 8 8 8 5.6 5.6 5.6 8.9 8.9 8.9 14.4 14.4 14.4 11.9 11.9 11.9 7.7 7.7 7.77.8 7.8 7.8 10.4 10.4 10.4 6.7 6.7 6.7 10.3 10.3 10.3 4.7 4.7 4.7 13.3 13.3 13.3 16.2 16.2 16.2 17.2 17.2 17.2 18.9 18.9 18.9 13.4 13.4 13.4 16.5 16.5 16.5 7.9 7.9 7.9 12.2 12.2 12.2 8.9 8.9 8.9 12.7 12.7 12.7 15.6 15.6 15.6 10.2 10.2 10.2 8 8 8 20 20 20 Deploy IKIOI 2019/01… 2019/02/01 2019/02/15 2019/03/01 2019/03/15 2019/03/29 2019/04/12 2019/05/03 2019/05/17 2019/05/31 2019/06/14 2019/06/28 2019/07/12 2019/07/26 2019/08/09 0 20 40 60 ここ数ヶ月のIKIOI Deploy / week / Power 例) 2019/01 週のIKIOI は 8 / 1 / 2 = 4 7 月の本番Deploy 数は114 回

Slide 60

Slide 60 text

毎週誰かが何かを良くしてる「よくする週」 というものがありました 今は3ヶ月に1回誰かがIKIOI をただひたすらに良くする「IKIOI 人」を 実施 SRE チームで基盤の作り直しなど CI / CD 高速化 CircleCI の処理高速化・並列数増加 Cloud Builder でのイメージビルド高速化 Spinnaker でデプロイまでの時間を短縮( 人が介入しないフローに) 開発合宿 https://tech.mfkessai.co.jp/2019/06/ikioi/ tech.mfkessai.co.jp DevOpsパフォーマンス 改善開発合宿 | MF KESSAI TECH BLOG 企業間後払い決済サービス「MF KESSAI」を運営するMF KESSAI株式会社 の技術ブログです。… IKIOI 向上に向けての取り組み https://tech.mfkessai.co.jp/2019/06/ikioi/

Slide 61

Slide 61 text

最終的に開発したらすぐ出せる状態とかそういった理想を描いて、 これからもIKOI を向上していきます IKIOI のこれから

Slide 62

Slide 62 text

採用に関する考え方と案内

Slide 63

Slide 63 text

採用に対する思い MF KESSAI の良い部分と悪い部分 どちらも知ってもらった上で、一緒に働きたい。 そのため選考に関して可能な限りオープンにすることを大切に しています。

Slide 64

Slide 64 text

ハンドブック github.com mfkessai/handbook handbook. Contribute to mfkessai/handbook development by creating an account on GitHub.… MF KESSAI という会社はB2B という事もあり、 個人ではなかなかイメージすることが難しいと思っています。 なのでGithub にhandbook を公開する事で誰でも会社、事業、チーム、アーキテクチャ、 採用に関しての考え方を閲覧することができるようにしています。 https://github.com/mfkessai/handbook/blob/master/guide/b ackend- interview.md

Slide 65

Slide 65 text

採用ガイド github.com mfkessai/handbook handbook. Contribute to mfkessai/handbook development by creating an account on GitHub.… https://github.com/mfkessai/handbook/blob/master/guide/b ackend- interview.md

Slide 66

Slide 66 text

最後に

Slide 67

Slide 67 text

herp.careers ソフトウェアエンジニア (Backend) - MF KESSAI株式会社 MF KESSAI株式会社では現在ソフトウェ アエンジニア(Backend)を募集してい ます。… herp.careers ソフトウェアエンジニア (Frontend) - MF KESSAI株式会社 MF KESSAI株式会社では現在ソフトウェ アエンジニア(Frontend)を募集してい ます。… herp.careers ソフトウェアエンジニア (Site Reliability) - MF KESSAI株式会社 MF KESSAI株式会社では現在ソフトウェ アエンジニア(Site Reliability)を募集し ています。… www.wantedly.com あらゆる経験をして新規 事業をゼロから創るサー ビスデザイナー募集! by 株式会社マネーフォ ワード マネーフォワードの法人・個人事業主向 けサービスは“企業のお金のプラットフォ ーム”をテーマに掲げ、 企業の【お金の流 れの計算・把握・管理...… おまちしております

Slide 68

Slide 68 text

オリジナルのThe Go gopher(Gopher くん) は、Renée French によってデザインされ、CC BY 3.0 ライセンスが適用されています。 https://github.com/egonelbre/gophers 内のGopher はCC 0 ライセンスで利用可能 1. 2. スライド内の各ライセンス周り

Slide 69

Slide 69 text

No content