はてなブックマーク

なお、弊社はベンダーとしてはDatadog、言語としてはGoを使っているのでその前提でこのブログを書きますが、その他のベンダー、言語でも参考になると思います。 Baggageに含めるとよさそうなもの よくあげられる例としては、UserIDやProductID、ソースIPアドレスなどのリクエストに紐づくデータが挙げられます。注意点として、誤って外部のベンダーにBaggageが渡ってしまう（注意しないとあり得ます）ことを考慮し、セキュアな情報は含めないようにすべきです。 他には、featureフラグを運用しているのであれば、feature情報をBaggageに含めると良いでしょう。 BFFなどの通信の入り口でどのfeatureかを判断し、その後のマイクロサービス間での通信はその情報を常に渡してあげることでマイクロサービス全体で同じfeatureを提供することができます。 以前、軽量featur

何か Kyashでサーバサイドのエンジニアをしているhirobeです。 業務でサーバサイドのアプリケーションへのfeature flag導入を提案および設計をしました。 どのような設計や実装にするか、なぜそうしたかを整理します。 なお、アプリケーションの特性としては以下を念頭に入れていただければと思います。 新規プロダクトではなく、5年以上動いている既存プロダクトに導入する サーバサイドアプリケーションのみをスコープとする 20~30のマイクロサービスから構成されている マイクロサービス間はREST/gRPC/SQSで通信されている そもそもなぜ導入するのか？ 目的を整理しておきます！ featureブランチからmainブランチにmergeされるまでの期間が長いために、以下のような問題がありました。 複数の機能開発の修正がconflictする可能性があり、またそれに気づくのが遅れる可能性が

はじめに はじめまして。Kyashでサーバサイドエンジニアを担当しているhirobeです。 Kyash Advent Calendar 2021の12/5担当分です。 Kyashでは、約30ほどのマイクロサービスが動いてます。 マイクロサービスは難しいです。 私が入社して2年半ほどの間、マイクロサービスの複雑さに苦しめられ、あがいてきた実経験をもとに、マイクロサービスにひそむ難しさを紹介したいと思います。 ここでは、ケースとして、弊社の機能のひとつである登録カードからのリンクを実装する上で発生する問題を紹介したいと思います。もちろん弊社サービスを使ったことない人でもわかるように説明をしますのでご安心ください。 なお、最初に注意書きしておくと、本ブログではあくまで「マイクロサービスにひそむ複雑さとその対応法」を説明するためのわかりやすさを優先して説明していきます。事実とは異なるケースがありま

はじめに TCPの仕様やconnect、write、read等のソケット関連のシステムコールの振る舞いを正確に理解するのはとても難しい。 正常系はそうでもないが、「どの程度パケットは再送されるのか」、「〜状態で〜のシステムコールはどのerrnoを返すのか」など異常系が難しい。また、これらの情報はWEB上だと良質な情報が比較的少ないように思う。 ここでは、挙動の説明は諦め1、挙動を確認するためのコマンドやコード群を紹介したい。 なお、普通のバックエンドエンジニアをしている人間で、ネットワークのスペシャリストではないので間違っている可能性は多分にある。ただ、ここで説明することは全て動作確認はしている。動作確認した環境はこちらにある。 コマンド 説明 ss -tanpo tcp(t)の全状態(a)をポート番号のまま(n)プロセス情報(p)とタイマー情報付き(o)で表示する。 ssは継続的な状態確

tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話CTCP はじめに サーバがコネクションをclose後しばらくして、クライアントがwriteしました。関数呼び出しの結果はエラーでしょうか？ 上記の正解は「何事もなく、成功する」です。この挙動が理解できている方はこの記事を読む必要はないかもしれません。 自分は「接続先がcloseしたソケットにwriteした場合はプロセスがSIG-PIPEを受け取るかシグナルをハンドリングしていた場合はEPIPEが返ってくる」と思っていました。 それは、Linuxのマニュアルに以下の記載があるためです。 EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writin

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 以前、tcpの仕様上、接続先がコネクションをcloseしているかはパケットを一度は実際に送るまでわからないよという話という記事をかいたのですが、そのきっかけは 以前、アプリからDBにSQLを投げたところ、コネクションがinvalidだというエラーが起きました。この原因自体はとても簡単でサーバ側(DB側)のコネクションを保持するタイムアウト設定がクライアントよりも短かったというだけなのですが、「これってクライアントライブラリ側でソケットにwriteした時点でエラーになるんだからハンドリングしてコネクションプールに保持している他の

はじめに Goのhttp.Request構造体のctxはdocによると、以下の場合にcancelされます。 For outgoing client requests, the context controls cancellation. For incoming server requests, the context is canceled when the client's connection closes, the request is canceled (with HTTP/2), or when the ServeHTTP method returns. クライアントがタイムアウトを設定していた場合にもタイムアウト時間経過後にコネクションがcloseされるため、サーバ側実装でcontextを参照することでタイムアウトしたことも気づけることになります。 Request.ctxやそ

はじめに 30才になったのを機にアウトプットを意識していこうと思います。 最初のテーマは地味ですが、ご興味あれば。 現在、自分は、Hadoop,Spark,Kafka,Fluentdなどを導入し、社内のログ基盤を整えようとしています。 Kafkaでシリアライズするには、Avro,SchemaRegistryを利用するのがメジャーであるが、 何も考えずにすぐ動くAvroのソースや一歩踏み込んだ説明がなかなか見つからず、なかなか理解できず苦しんだので、誰かの助けになればと思います。 SchemaRegistryはAvroについて理解できれば難しくないと思うので軽く触れる程度です。 また、コードはGitHubにあげてますので、参考までに。 なお、基本的に既に良質なものがあればリンクだけ張って、説明はそちらに譲るというスタンスでいきます。 Avroとは 1分で読めるので、Avro本家のOvervi

はじめに 現在の会社で、半年ほど前からログ分析基盤の構築に取り組み、昨日試験的に本番運用を迎えました。 これを機にアーキテクチャの振り返りを会社のブログにて公表しましたので、こちらでも紹介したい思います。 基本的には内容は同じですので、見やすい方で見ていただければと思います。 また、リンクを辿っていただければ、他の社員が書いたブログもたくさんありますので、興味持っていただければ幸いです。 解決したかった課題 当社では、ここ１，２年ユーザ行動ログ等のさまざまなデータを機械学習等の分析につなげようという動きが多くなっておりますが、主に以下の二つにより、分析、及び分析の結果を用いたアプリの作成が制限されてしまっておりました。 ログが一台のサーバのPostgresにhstore形式にて格納されている Postgresは分析に適していない スケールしない（複数サーバによりクラスタリング構成を組めない