MF KESSAI開発合宿運営のgarsueです。 前回に引き続き、チーム対抗パフォーマンス改善合宿の様子をお送りします。
今回は結果編として、実際にどういう改善が行われたかをお伝えします。
合宿でパフォーマンス改善に取り組む前日、GoogleでCloud Profilerをご担当なさってる山口(ymotongpoo)さんのご協力のもと、Cloud Profilerのハンズオンを実施していただきました。 ハンズオンの概要についてはチーム対抗パフォーマンス改善合宿 準備編をご覧ください。
そのおかげで「プロファイルを取る」「ボトルネックを見つける」「改善に向けて改修する」「実際に改善できたか再度プロファイラーで確認する」というパフォーマンス改善サイクルを各メンバーが身についていました。
このサイクルのなかで見つけたボトルネックと、実際に効果のあった改善について紹介していきます。
MF KESSAIでバックエンドのエンジニアをやっているgarsueです。 先日当社のnoteのインタビュー企画でNestJSを使ったBackend For Frontend(以下BFF)について「ブログお待ちしてます！」と言われてしまったので、重い腰を上げて書くことにしました。
当社ではNestJSをGraphQLをしゃべるBFFとして使っているので、そのあたりの勘所や知見を少し紹介します。
まず、フロントエンドのフレームワークはNuxtJSで決まっていました。当社での2年以上の実績もあり、もはや定番となっています。 また、NuxtJSと合わせてGraphQLを使うのも定番となっており、今回もGraphQLを使うことが決まっていました。
NuxtJSから呼び出すBFFは今までGoでgqlgenを使ったGraphQLサーバーとして実装していました。 これはこれで悪くないのですが、やりたいことはバックエンドのサービス群を呼び出してフロントエンドの都合のいい形に加工して返すことぐらいなので、もっと軽く開発できる何かにしたいなとも思っていました。
そこで高い抽象度で記述量も少なく抑えられ、フロントエンドエンジニアも触りやすいTypeScript製のフレームワークであるNestJSを採用しました。 GraphQLもサポートされていて、NestJS自体がマイクロサービスアーキテクチャを前提にしてるフレームワークでもあり、今回の要件にマッチしていました。
こんにちは、MF KESSAIでバックエンドのエンジニアのgarsueです。
2019年もあっという間すぎて戦慄しています。
今回はMF KESSAIでのGoのテストについて、ちょっと工夫してる点を書いてみようと思います。
Go標準のテスト実行コマンドgo testはデフォルトでパッケージごとにテストを並列実行します。
通常は何もしなくてもテストが並列実行されてうれしいのですが、たまに困るケースがあります。
こんにちは、獏良天の風神こと@garsueです。 MF KESSAIでバックエンドのエンジニアをやってます。
先日、OpenCensus meetup vol.1にブログ枠として参加しました。 今回はそのイベントレポートとぼくなりの感想を書いていこうと思います。
マイクロサービスやサーバーレスアーキテクチャなど、複雑化・分散化していく昨今のシステムでは、システム全体の状態を把握することが困難になってきました。 フロントエンド、クライアントサイドも年々複雑になっていますが、バックエンド以上に状態を観測することが困難です。
システム全体のいつ・どこで・何が・どうなっているかを把握できるようにすること、すなわちオブザーバビリティ（Observability、可観測性）1の担保が課題になっています。
その課題解決の一助となる技術としてOpenCensus2が注目されています。
しかし、まだよく知らない・気になっているという人が大部分ということもあり、実際にOpenCensusを使っている人を中心に情報交換をする場としてOpenCensus meetupが開催されました。