マイクロサービス間通信における認証認可およびアクセス制御
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
UbieにおけるGo言語のエラーハンドリング
背景 Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。 Go言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツールなどではエラーの内容が簡潔に表せてよいのですが、サーバサイドアプリケーションのようにエラーにまつわる情報を詳細に残してあとから調査に利用する、という場面では不向きです。特に本番環境でしか再現しないようなエラーの場合は、いかに関連情報を残せているかが、問題の解決に大きく影響します。 先日も話題になっていました
Ubie は Go と Node.js の会社になります
Ubie では、創業当初から Server-Side Kotlin を推進してきましたが、全社的な技術選定を再度行い、これからは Go と Node.js を中心とすることにしました。 本記事では、Go と Node.js を選定した理由や、それを普及させる取り組み、そして選定の流れを紹介します。 経緯 これまで Ubie では技術スタックを発散させてきていて、現在は Kotlin、Go、Node.js、Ruby、Python のバックエンドサービスが動いています。以前は新規開発が多く、それぞれに携わるメンバーが技術選定をすることにより、最大瞬間風速を出せるなどのメリットがありました。しかし、現在では弊害が目立ってきています。 まず、事業成長に伴って運用の重要性が増しています。人材が潤沢とは言えないスタートアップにおいて、様々な技術スタックを安定運用することはコストが高すぎると感じています
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
