ビジネスカンパニー初採用のデータアナリストが入社3ヶ月を総括する

初めまして、石井貴久です。個人事業主本部マーケティング部のデータアナリストです。
2021年10月1日に入社してからの3ヶ月間を総括しつつ、アナリスト職のやりがいや面白さを伝えたく筆を執りました。どうぞ最後までよろしくお願いします。

目次

  1. 何で入社したの?
  2. 何をやったの?
  3. 何をしたいの?
  4. 謝辞

1. 何で入社したの?

面接で部長の加藤さんや、(前)本部長の田平さんの人柄に惹かれたのが入社の決め手です。

面接を通じて、個人事業主のお金の悩みをマネーフォワードで解決したいと思いました。

まず最たるものは、マネーフォワード クラウド確定申告をもっと多くのユーザに使って頂き、仕訳記帳や確定申告の手間を減らすことです!

また、その前段階として転職活動の軸に据えていた「共感・貢献・成長」の3点が、マネーフォワードとマッチしました。

  1. 共感:マネーフォワードが提供するサービスや、Mission, Vision, Value, Culture (MVVC) に魅力を感じました。
    お金の悩みを少しでも減らそう/無くそうと、真正面から取り組む姿勢に共感しました。
  2. 貢献:新卒で資産運用会社で働いた際の金融業界の経験/ドメイン知識や、前職でデータサイエンティストとして獲得したIT/分析スキルを掛け合わせて、金融×ITの分野に貢献したくなりました。
    お金の管理を効率化してラクになり、運用も高度化してお金自身に働いてもらおうと思いました。
  3. 成長:ユーザに近い現場で多種多様なデータを扱い、ビジネスの意思決定に影響を与えられるポジションで働きたくなりました。
    課題発見や分析、可視化等を通じて、マネーフォワードの成長と共に私も成長したいと思いました。

自分が事前に定めた評価指標を満たし、事後的に魅力も加わって、入社を決意しました!

続きを読む

Go言語でDeep Copyする方法

この記事はマネーフォワードアドベントカレンダー2021🎄の22日目の記事です。

経理財務プロダクト本部でソフトウェアエンジニアをしている鈴木です。
開発を行っていてふとGo言語でDeep Copyをやりたいと考え、どのような実現方法があるか調査しました。

Deep Copy

Deep Copyとはオブジェクトを別の実体としてコピーすることです。
詳しくはGoogle検索してもらえればわかりやすい例がたくさん出てきます。
Deep Copyを行うためのハードルとしてGo言語ではポインタ型やSlice、Map型の存在があります。
これらの型は値としてメモリアドレス値を保持しており、代入演算子=にてコピーを行ってもコピーされるものはメモリアドレス値であるため、同じ実体を指し示してしまいます。
これらの型に対して特別な操作でコピーする必要があるため単純な代入演算子=だけではディープコピーが実現できません。

Go言語でDeep Copy

Go言語でポインタ型やslice, mapのディープコピーを行うためにはGo言語では代入=ではなく、それらの型に合わせた操作を行う必要があります。

続きを読む

BtoB SaaSに捧ぐマイクロサービスのはじめの一歩

この記事はマネーフォワードアドベントカレンダー2021🎄21日目の記事です。

昨日はDanさんで、「GraphQL Federationはどのように動かしますか?」でした。

こんにちは。
経理財務プロダクト本部 アーキテクトグループでアーキテクトエンジニアをしていますchibicco(@chibiccoooooo)です。

ERPやBtoB SaaSを作っていて、これからマイクロサービス化を進める人たちに向けて、私がマイクロサービス化で最初にやった事をお話しします。

背景

前提として、マネーフォワード クラウド会計(以後、クラウド会計と表記)をマイクロサービス化しなければ、となったとき以下のような背景がありました。

  • クラウド会計のリポジトリ巨大化によって、開発速度が低下する
  • そのリポジトリをメンテナンスし続けることでひとつの技術に縛られることになり、技術者のスキル向上につながらない
  • さらに、マネーフォワード全社で部分的にマイクロサービス化していくぞという流れが後押し

マイクロサービス化によって開発速度が向上し、最終的にユーザ価値につながるためこのような意思決定をしました。
しかし、マイクロサービス化するといっても、いきなり設計ができるわけではありません。

続きを読む

GraphQL Federationはどのように動かしますか?

この記事は、Money Forward Engineering Advent Calendar 2021 20日目の投稿です。

こんにちは、マネーフォワード Pay for Businessを開発するPay事業本部の開発者のダンと申します。

前回はGraphQL Federation – API Gatewayの進化の記事にGraphQL Federationを採用することでいいマイクロサービスアキテクチャが実現できたことについて紹介しました。この記事を読む前に、前回の記事を事前に読むことをおすすめます。

まずGraphQL Federation – API Gatewayの進化で紹介した内容を復習します。

  • GraphQL Federationの利点は:
    • バックエンド側に複数マイクロサービスが提供した複数のGraphQL APIsはGraphQL Federation仕組みにより一つのサービスの一つのGraphQL APIとしてクライアントに提供します。
    • 各サービスはFederationの仕様に沿って実装すれば良くて、Gatewayはビジネスロジックがなく、主にルーティングの役割でクライアントからリクエストを適切なサービスに送ります。
    • 上はFederation仕組みに与えた利点ですが、名前の通りもちろんGraphQL自体の利点全てあります。

この記事にはGraphQL Federationは上の利点を得るのためどのように動かすかということについて説明させていただきます。

記事の構成

  1. GraphQL Federationのアーキテクチャー
  2. 各サービスのsubgraphを作成します
  3. subgraphsから一つのsupergraphを作成します
  4. Gatewayでクライアントからのリクエストをどのように解決ますか
  5. 最後に

1. GraphQL Federationアーキテクチャー

GraphQL Federationアーキテクチャーを見ていきましょう。

  • 図の一番下はマイクロサービス群です。各サービスが提供するGraphQL APIはsubgraphと呼ばれます。そのsubgraphはGraphQL仕様を拡張するApollo Federation subgraph 仕様に沿って実装されました。

続きを読む

IRSAをマルチアカウントAWS環境のEKSクラスタに導入した話

この記事は、Money Forward Engineering Advent Calendar 2021 19日目の投稿です。

こんにちは。
マネーフォワードでエンジニアとして働いているgotoken(@kennygt51)です。
今回は、当社の提供するサービスの一部が稼働している、マルチアカウントAWS環境のEKSクラスタにIRSA(IAM Roles for Service Accounts)を導入した話をします。

IRSAは何を目的としているか?

実際の導入事例について紹介する前に、IRSAとは「何を目的とした機能なのか?」「どのような仕組みなのか?」という点について紹介します。

IRSAとは 「EKSクラスタ上で稼働するPodに対してIAMロールを割り当てる仕組み」 です。

EKS上のPodで稼働するアプリケーションがAWSのリソース(S3やSQSなど)にアクセスする場合、(EC2上で稼働するアプリケーションと同様に)適切なIAMポリシーを付与したIAMロールを割り当てることで、対象のAWSリソースへのアクセスを許可する必要があります。
2019年9月以前は、Pod単位でIAMロールを付与する仕組みがAWS公式でサポートされておらず、Worker NodeのIAMロールにIAMポリシーを付与する必要がありました。このような方式は「Node及びNode上のPodが同じ権限を持ってしまい、最小権限の法則に反する」という課題がありました。(やりたいことを実現するためにはkiamのようなサードパーティのOSSを導入する必要がありました)

続きを読む

「Vue Test Utils」を導入して、Vue Componentの単体テストを書けるようにした話

はじめに

初めまして。「マネーフォワード クラウド勤怠」のエンジニアのkatuoです。

私の所属しているチームでは、発生したバグの分析や振り返りをするMTGが週単位で定期的に行われています。

このMTGを実施する中で、ユーザーアクションを伴ったブラウザテストやE2Eテストのようなものがあればバグの混入に気付けたという事例がいくつか出てくるようになりました。

とはいえ、実際にデプロイ毎にブラウザでの手動テストを全て実施するのはコストが高く現実的ではないですし、一方、E2Eテストを採用するにしても、導入・保守のコストも高く付くので、新機能開発に追われる現状のチーム状態を鑑みると導入するのは中々ハードルが高い状況でした。このような理由から、まずはE2Eテストほどの網羅性はないが、導入・保守のコストが低い単体テストの導入に舵を切ることにしました。

そして今回、コンポーネントの単体テストを環境を提供するライブラリ「Vue Test Utils」を採用しました。採用理由はシンプルで「 Vue.js公式単体テストライブラリである」と「公式ドキュメントが充実している」の2点です。

Vue Test Utils とは

上でも述べましたが、Vue.jsの公式単体テストライブラリで、テスト実行時にVue コンポーネントをマウントし、Vue Test Utilsが提供するクリックイベントなどのユーザーアクションやpropsといったインプットなどのモックを利用することで、コンポーネントのアウトプットをテストすることができます。

続きを読む

拝啓、ブログの進捗が出ない君へ。1日30分から始められるペアブロギングで、ネタ出しから公開までのハードルを下げよう

やっはろー。
2021年10月からマネーフォワード クラウド勤怠の開発チームでSREとして働いています、VTRyo です。

この記事は、Money Forward Engineering Advent Calendar 2021 16日目の投稿です。

さて、Datadogダッシュボードのブログを書いて以来の登場です。
開発者でも取り組める!発展期のサービスこそ、SLOやDatadogダッシュボードで状態を可視化してメンバーに安心を届けよう

実は入社当月から毎月エンジニアブログを投稿しています。
と言っても、僕ひとりが書ける記事の数なんてたかが知れています。
毎週のように書けるほどネタがあるわけでもないので、もっと自分たちのチームのことを知ってもらいたい!と思ったとき、どうすればよいでしょうか。

答えは、 書きたがってる人を支援すること です。

1日30分、僕に時間をくれませんか

入社してから淡々とブログ書いていて、皆も書ける人はぜひやってみてください〜と地道に宣伝していました。
そういう中で、このようなコメントを貰いました。

続きを読む

How MySQL Multi-Threaded Slave (MTS) Works

この記事はマネーフォワードアドベントカレンダー 2021の15日目の記事です。

こんにちは。マネーフォワードサービス基盤本部インフラ部の@grezarです。先日、MySQLのMulti-Threaded Slave(以下、MTS)を本番で有効化した際にMTSの挙動について詳しく調査する機会があったのでこの記事で解説したいと思います。

そもそもMTSとは

MTS自体はMySQL5.6から登場したMySQLの機能で、従来のレプリケーションがシングルスレッドでしかトランザクションを実行できなかったところを、条件付きではあるものの、マルチスレッドで実行できるようにしたものです。これによって、高いスループットが求められるようなreplicaにおいてはシングルスレッドではレプリケーションの性能に限界があったところを一定の制約下のもと、マルチスレッドで実行することで高いスループットを実現することができるようになりました。MTSがどのようにマルチスレッドでのレプリケーションを可能にしているのかを理解する上で大切なのはprimary側でどのようにトランザクション間の依存を解決し、レプリケーション側では依存解決されたトランザクションをどのようなロジックに基づいて並列実行しているかを知ることです。これらのprimary側の依存解決のロジックと、replica側の並列実行のロジックの組み合わせによってMTSの動作は異なってきます。

MySQL5.6時点ではreplica側での並列実行方式にDATABASEというものが登場し、スキーマが別々のトランザクションに対してのみしかMTSを適用できませんでした。

MySQL5.7ではreplica側の並列実行方式にLOGICAL_CLOCKが加わり、これによってprimary側でグループコミットされたトランザクションについては同一スキーマであってもreplica側でもマルチスレッドで実行できるようになりました。

また、MySQL 5.7.22 及びMySQL 8からはprimary側のトランザクションの依存解決のアルゴリズムに(binlog_transaction_dependency_trackingにて指定)にWRITESET及びその亜種のWRITESET_SESSIONという方式が加わり、これによってトランザクションが変更した行に重複がない限りはグループコミットをしていなくてもreplica側での並列実行が可能になり、より高い並列性を実現できるようになりました。

現在では特殊な事情がない限りもっとも高い並列性を実現できるWRITESET(またはWRITESET_SESSION)とLOGICAL_CLOCKの組み合わせを使うのがよいと個人的には考えており、この記事では特にWRITESETによってprimary側でトランザクション間の依存解決がどのように行われるのかを詳しく解説していきます。

MTSにおける依存解決

当然の話しですが、トランザクションをreplicaで並列に実行しようと思ったらそのトランザクションは依存しているトランザクションのCOMMIT後に実行される必要があります。そうでなければトランザクションの実行順序が前後することによってprimaryとのデータの不整合が起きたり、そもそもトランザクションの実行自体に失敗するでしょう。これはシングルスレッドで直列にレプリケーションをしているような状態では問題になりません。単にマスターでCOMMITされた順番で実行していくことになるので通常は同じ条件で素直に実行していけば整合性が保たれます。

ただし、マルチスレッドでレプリケーションを実行する場合はこの限りではありません。MTSではマルチスレッドでレプリケーションを実行しますが、トランザクション間の依存解決をしない場合マスターと同じ順番で直列にトランザクションを実行していくことしかできません。なぜなら依存解決されていないトランザクションを同時に実行した場合には不整合が生じる可能性があるからです。そこで、マルチスレッドを活かしてレプリケーションの性能を出すためにはトランザクション間の依存の解決をどのように行うのかが重要になってきます。

マルチスレッドのレプリケーションで性能を出すためには実行可能な状態になったトランザクションをできるだけ早い段階から実行していく、すなわちあるトランザクションが依存しているトランザクションをできるだけ古いもの(sequence_numberが若いもの)に解決しておいて、そのトランザクションがCOMMITされた直後から実行していくということが大切になります。この依存の解決があまり賢くないとトランザクション実行までに待たなければならない時間が増えてしまいマルチスレッドを活かしきれなくなってしまいます。依存解決の最終的な目的は、あるトランザクションよりも前にCOMMITされていなければならないトランザクションのうち、可能な限り前に実行されたトランザクションを特定することです。

MTSではトランザクション間の依存の解決をprimary側で行い、その情報をbinlogに含めます。replica側ではbinlogに含まれた情報をもとに並列実行可能なトランザクションを判断し、並列で実行します。MTSを有効にしたときにreplica側でトランザクション間の並列実行可否の判定に利用するのが last_committedsequence_number です。sequence_number は単純にトランザクションごとに連番となるように振られる番号です。binlogのローテート時にも引き継がれます。last_committed はそのトランザクションを実行するよりも前にCOMMITされている必要があるトランザクションを示すものです。この条件を満たすようにreplica側ではトランザクションを並列に実行していきます。

(以下はmysqlbinlogコマンドの実行結果から抜粋したもの。binlogの各行にlast_commitedsequence_numberが含まれている)

#210617 18:26:30 server id xxxxxx  end_log_pos 522359145 CRC32 0x5df71671     GTID    last_committed=229643   sequence_number=229644  rbr_only=yes
#210617 18:26:31 server id xxxxxx  end_log_pos 522363726 CRC32 0x5fcd787d     GTID    last_committed=229644   sequence_number=229645  rbr_only=no
#210617 18:26:31 server id xxxxxx  end_log_pos 522363981 CRC32 0xf854f9f1     GTID    last_committed=229645   sequence_number=229646  rbr_only=yes
#210617 18:26:32 server id xxxxxx  end_log_pos 522364434 CRC32 0x5d52b735     GTID    last_committed=229645   sequence_number=229647  rbr_only=yes
#210617 18:26:32 server id xxxxxx  end_log_pos 522366622 CRC32 0xb9558655     GTID    last_committed=229645   sequence_number=229648  rbr_only=yes
#210617 18:26:37 server id xxxxxx  end_log_pos 522368805 CRC32 0xbbc0aa51     GTID    last_committed=229645   sequence_number=229649  rbr_only=yes
#210617 18:26:37 server id xxxxxx  end_log_pos 522370014 CRC32 0x60d4521b     GTID    last_committed=229645   sequence_number=229650  rbr_only=yes

先程も述べましたが、MTSはprimary側でのトランザクション間の依存解決のロジックとreplica側での並列実行方式の組み合わせによってどのように動作するかが変わります。
それぞれ設定上のパラメータとしてはprimaryがbinlog_transaction_dependency_tracking 、replicaはreplica_parallel_typeで指定します。

binlog_transaction_dependency_trackingには COMMIT_ORDERとWRITESET(またはWRITESET_SESSION)replica_parallel_typeには *DATABASELOGICAL_CLOCK の2つが指定可能です。ではそれぞれのパラメータがどのようにMTSの動作に影響を与えるかをより詳しく見ていきます。

続きを読む

ポエムは恥だが役に立つ

TL;DR

この記事は、マネーフォワード関西拠点 Advent Calendar 2021 🎄15日目の投稿です、担当は技術広報をしている luccafort です。
14日目は nabe_rey(なべれい)さんで 関西へリロケーションしませんか? でした。

この記事では入社して半年くらいたったときにある日ふと思い立って「チームにJoinして効率よく信頼貯金を貯めるHowTo」というポエムを書いて満足していたらいつの間にか社内のスクーリングチャンネルで共有されていたでござる…という話をご紹介します。

いい話なので社内はもちろん、Motto世の中にポエミーな文章があふれていてほしいし、ためになる話だけじゃなくてくだらないポエムが役に立つこともあるんだよ…ということがお伝えできればなと思っています。

書くきっかけはポエムがスクーリングで共有されているよ!と教えてくれた流れから「いい話だよね!」といってもらえたことで「よっしゃ、書くか!」となりました。
人類は愚か。

余談ですが、「スクーリングってなんだろう?」となったかたもいると思うので簡単に説明すると、入社直後にあるオンボーディングの一種だと捉えてもらえればイメージしやすいかなと思います。

マネーフォワード クラウドシリーズ関連部署の配属者に対して実施する、各プロダクトの基本的な機能や特徴を理解してもらうための導入カリキュラム

正式には上記がマネーフォワードのスクーリングの概念の説明になりますが、オンボーディングや研修のときに社内ポエムとして書かれた記事が参照された、といえば事態が伝わるかなと思います。

なぜ件のポエムを書こうと思ったのか?

全くなんで書こうと思ったのか思い出せないので頑張って思い出そうとしました……が完全にこの世から記憶は失われてしまいました。
いかんせん1年以上前のことで完全に忘却の彼方に飛んでいってしまったので仕方ないですね!
書いたあとで社内のチャットツールに下記のような投稿をしていることまでは突き止めました。
大喜利してないでさっさと寝ろといいたい。

続きを読む

QAが開発にチームに入り込むときにやっておきたい、”何もしない”から始めるQA活動

こんにちは!マネーフォワードのHR領域でQAエンジニアをしている森田です。

前回に続き、2回目のエンジニアブログ投稿になります。

現在私は、クラウド勤怠チームのQAスキル向上を目指して奮闘中です。
今回は、その最初の取り組みについて紹介します。

HR領域のQAグループが目指している方向性については、こちらをご覧ください!
QA組織立ち上げ奮闘記〜想いが人を吸い寄せる〜

前提

HR領域の開発チームとQAチームはそれぞれ別のチームとして存在しています。
これまで、HR領域ではQAチームはなく、開発チーム内で設計からテストまで実施して、サービスをリリースしていました。
そして、開発チームがQAのことを全く知らない可能性があるという状態でした。

背景

いきなり他のチームの人が入ってきて、あーしろこーしろと言われても、受け入れてもらえないのでは、という心配がありました。また、私がどんな人かを知ってもらわないと、言葉の説得力もないと思います。

そこで、“何もしない” から始めることにしました。

“何もしない”を実行する

“何もしない”とはいいつつも、全くアクションを起こさないわけではありません。
“何もしない”とは、「口は挟まないけれど、伝えることは伝え、把握することは把握する」という意味です。

  • 口を挟まない
    • もっとこうしたら良い、こうすべき、とアドバイスしたいのをグッとこらえる
  • 伝えることは伝える
    • 自分(QA)は何者かを話す
  • 把握することは把握する
    • スクラムのミーティングに参加する

続きを読む