MF KESSAI SRE（兼CTO）の @shinofara です。
いきなりですが、皆さんはどの様に秘密情報の管理と配布を行っていますか？
https://tech.mfkessai.co.jp/2017/07/1/ を公開した2017/07/31時点では、Google Kubernetes Engine(GKE)を中心としたシンプルなアーキテクチャでした。
当初はKubernetes Secretだけですので特に問題は無かったのですが、2年半と時間が立つことで目的に応じて利用するサービスも増えた事で Google App Engine(GAE/Se and GAE/Flex),Cloud Function(CF),Cloud Runなどのうえで、複数のアプリケーションが動く状態になってます。
今回の記事では、複数のアプリケーションが異なる環境で動く状態となり大変になってきた秘密情報管理と配布方法をふりかえりたいと思います。 そしてどういう管理配布方法に落ち着いたのかをご紹介させていただければと思っております。
MF KESSAI(以下MFK)でAPI開発を担当している@usumachiです。
MFKでは予てよりAPIを提供してきましたが、需要の変化やサービスの変化に合わせてVersion2(以下v2)の開発を進めています。 今回はv2のベータリリースにあたって僕のAPIv2への考えをお伝えしたいと思います。
Version2のドキュメントはこちらです。
MF KESSAI API v2
MF KESSAI開発合宿運営（CTO）の @shinofara です。
本日はマネーフォワードグループのエンジニアが集う開発合宿にMF KESSAI（以下MFK）も参加しています。 合宿は個人やチーム単位でテーマを持って開発するスタイルなので、MFKはこの場を借りて、第5回目の開発合宿を行うことにしました。
ですが今回の記事はちょうど3か月前の3月13日、14日に開催した開発合宿の内容をお話したいと思います。
過去には「技術研鑽」「場所を変えて仕事」「開発組織を今後どの様によりよくしていくか」などざっくりとしたテーマで開催してきましたが、今回は「開発のIKIOIを向上させ続ける」をテーマにしました。
IKIOIとは弊社の1つのチームで自分たちのスループットを図る指標として生まれて、今では全チームが観測してるチーム開発力を示す指標となってます。
今回は、OpenAPI Specification(以下OAS)駆動でREST API開発をすることで享受できる恩恵と制限についてお伝えできればと思っています。
MF KESSAI(以下MFK)で、Backend開発を行っているusumachi(a.k.a usuimachinami)と申します。 開発に対し “気合ブリバリ” でそれはもう横須賀最強 麓沙亜鵺です。
さて、MFKでは導入企業様のさらなる請求業務の効率化を目指し、REST APIを提供しています。 開発に際してインターフェースの仕様定義のために、OASを利用して開発を行っています。
また、最近のMFKは試作（prototyping）を繰り返してより良いものを作ろうという動きがあります。 この方針とOASを利用した開発がとても適合しました。
こんにちは、獏良天の風神こと@garsueです。 MF KESSAIでバックエンドのエンジニアをやってます。
先日、OpenCensus meetup vol.1にブログ枠として参加しました。 今回はそのイベントレポートとぼくなりの感想を書いていこうと思います。
マイクロサービスやサーバーレスアーキテクチャなど、複雑化・分散化していく昨今のシステムでは、システム全体の状態を把握することが困難になってきました。 フロントエンド、クライアントサイドも年々複雑になっていますが、バックエンド以上に状態を観測することが困難です。
システム全体のいつ・どこで・何が・どうなっているかを把握できるようにすること、すなわちオブザーバビリティ（Observability、可観測性）1の担保が課題になっています。
その課題解決の一助となる技術としてOpenCensus2が注目されています。
しかし、まだよく知らない・気になっているという人が大部分ということもあり、実際にOpenCensusを使っている人を中心に情報交換をする場としてOpenCensus meetupが開催されました。