この記事は、LayerX Tech Advent Calendar 2024 の9日目の記事です。 昨日は budougumi0617 さんによるリクエストログミドルウェアに後続ロジックから情報を渡したいときの2つのアプローチでした。確かにな〜という課題感と、懸念はありつつもちゃんと検討した上で決め切る姿勢が良いなという記事でした。 すべての経済活動をデジタル化するためにすべての業務活動をデジタル化したい、コーポレートエンジニアリング室アプリケーションチームの @yuya-takeyama です。 アプリケーションチームはソフトウェアエンジニアリングに対する理解と開発力を持ち、「技術をつくる」ことによる課題解決をしていくチームとなっています。 昨今は社内で利用する各種 SaaS だったり様々な業務の間でのスムーズなデータ連携が課題になっており、その辺の話をしていきます。 直近でもブログやイ

はじめに どうもみなさんお世話になってます @convto です。 最近ちらちら直近のGoのCVEとかみてるので、危険度は度外視してパっとみて面白かったCVEとそのパッチの感想みたいなのをまとめつつバージョンアップを啓蒙していきます。 みんなバージョンアップすぐやろうな！ これは Kyash Advent Calendar 2022 の2日目の記事だよ。 CVE情報の集め方 Goに関するCVEは基本的に修正パッチ提供後にメーリスで流れてきます。はいってればいろいろ見れるはずです。 https://groups.google.com/g/golang-announce [security] prefixがあるのがセキュリティ関連の情報を含んでます。ここから任意のCVEをさがせばよいです。 CVEの修正パッチの探し方 メーリスから探してるならだいたい該当の投稿にissueチケットへのリンクがあ

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

Kyashの @convto です。 普段はサーバーサイドの開発をゴリゴリ頑張っていますが、お祭り事も好きなので開催予定のmeetupの運営についてもガッツリ関わっております。 2022/9/12(月) の13時から Kyash TechTalk #4 - Serversideと新しい挑戦 - connpass を開催するので、より広く知ってもらうために告知しつつ、YouTube Liveでお昼開催！などのチャレンジもしているので、そのあたりの狙いや背景を紹介できればなと思います！ kyash.connpass.com 開催の経緯 今年の4月ごろに Kyash TechTalk #2 - Serversideのシステム構成とアーキテクチャ - connpass を実施しました。 とてもありがたいことに多くのかたにご参加いただきKyashの取り組みを知っていただけました。ご参加いただいた皆様

はじめに 分散システムやってるとどこからでも安全に採番できる強い衝突耐性をもったuuid的なほげほげidがほしくなります。 世にほげほげidはたくさんありますが、適当にREADMEとかよんでもみんな「これイケてるで！」「uuidとかより文字数すくないで！」「sortableでうれしいで！」とかそういうことばっかいっててどの程度衝突耐性があるのかよくわからん問題があります 今回はほげほげidの構成要素の調査と衝突耐性をざっとまとめて比較しようと思います。 比較する項目 ざっくり random bit数 衝突耐性 ソートできるか その他メモ みたいな感じで整理して比較していきます。 衝突耐性は 衝突確率P=0.5のときの必要な試行回数 乱数以外の識別要素 の2つで評価します。たとえばtimestampとか入れてるやつは暗号学的な安全性には寄与しないけど実用上はある精度の時刻で識別できて衝突耐性

はじめに KyashでBackend Engineerをしている uncle__ko です。 この度、KyashのTech Teamの生産力を爆上げするべく新たにGrowth Technology Teamが発足しました。 このTeamが発足した背景や、これからどのようにプロダクトや組織に貢献していくのかを記載しようかと思います。 なぜ新Teamが発足したのか Kyashはいままで沢山の機能を世の中に届けてきました。 ここ数年で言えばKyash Cardなどのリアルカードの発行をはじめ、Apple Pay・Google Payへの対応、資金移動業を取得しての銀行口座入金リリース、 カテゴリ機能や共有口座機能、さらにはBNPL（後払い）サービスであるイマすぐ入金やKyashリワードなどです。 小さな機能も合わせればもっと沢山あります。 これだけのサービスを世の中にリリース出来ていれば生産性と

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

やりたいこと FAXで障害報告が送られて来たときにSlackに内容を通知してエンジニアが気がつけるようにしたい 前置き Kyashでサーバサイドエンジニアをやっている @uncle__ko です 色々なシステムやベンダーと接続をしていると障害報告がFAXで来るなんてこともあります 現実問題、FAXで連絡が来たところでリモートワークなこのご時世では気がつくことは困難 しかも休日や夜間にもFAXで届くこともあります レガシーだと嘆いていても仕方がないのでSlackに通知させて気がつけるようしたいと思います Zapier zapier.com ポチポチするだけで色々なツールを繋ぐことが出来る便利なやつです KyashではZapierを使って様々なものを自動化しています blog.kyash.co Zap Summary Trigger: FAX.PLUS FAX PLUSとはオンライン上でFAX

はじめに protobufのエンコーディングはwireという名前で以下に仕様がある developers.google.com 最近仕様を読んだりproto定義から生成される成果物を読んだりいろいろしていて、Unmarshalerかける気がしたので書いてみた。 すべての仕様に準拠するものは大変なので、現状はネストしない構造かつtypeがVarint(のenum以外)、Length-delimited(のstring, bytesのみ)だけサポートしている。 以下のようなproto定義で生成されるメッセージがUnmarshalできます message Test { int32 Int32 = 1; int64 Int64 = 2; bool Boolean = 3; sint32 Sint32 = 4; sint64 Sint64 = 5; string Str = 6; bytes Byt

bloom filter とは bloom filter とは、ざっくりいうと ある集合において、低コストにある要素が存在しないことがわかる データ構造です。 どのくらいコストが低いかというと、要素の登録や存在確認がともに O(k) です(kは利用するハッシュの数)。 集合の最大要素数や、実際に登録されているデータ数に影響されずに固定時間で結果を返せます。 特徴としては 登録、存在確認のコストが O(k) 「存在するよ！」といってるのに探してみたら存在しない場合がある(偽陽性がある) 「存在しないよ！」といったものは100%存在しない(偽陰性はない) なので、偽陽性が許容できる場合においては高速な存在確認としてつかえます。 想定できる使い方としては、探索コストが高いデータを検索する前にbloom filterをつかう、など。 しくみ 一言でいうと単語を複数のbit列のindex値に変換して

a = 入力A b = 入力B for (p = 0; p <= M, p++) { k ∈ [-p, Δ+1] { fp[k][p] = (k, max(fp(k-1, p) + 1, fp(k+1, p-1))) } k = Δ { fp[k][p] = snake(k, max(k-1, p) + 1, max(k+1, p)) } k ∈ [Δ+1, Δ+p] { snake(k, max(fp(k-1, p-1) + 1, fp(k+1, p))) } if (fp[Δ][p] == N) { return Δ + 2*P // Dの値を返す } } snake(k, y) int { x = y - k while (a[x] == b[y]) { x++ y++ } return y } Goによる実装 さきほどの擬似コードのような処理を実装すれば最短編集距離が導けます。 こ

はじめに これは、3回にわけて Wu らによる O(NP) アルゴリズムを解説、実装するシリーズです。 ①仕組み、考え方 ②探索方法 <- 今回 ③Goによる実装 の3部に分かれています。 今回も、前回に引き続き Wu らによる O(NP) アルゴリズムの解説をしていきたいと思います。 前回の ①仕組み、考え方編 では、大まかな考え方を整理して、なぜ計算量が下がるのかわかりました。 今回は、前回わかったことを利用して、実際にどう探索していくのかまとめていきます。 元論文は An O(NP) Sequence Comparison Algorithm by described by Sun Wu, Udi Manber and Gene Myers です。興味のある方はそちらも目を通すと面白いと思います。 最終的な実装を確認したい方は https://github.com/convto/on

はじめに 今回はテキストの差分検出などで使われる Wu らによる O(NP) のアルゴリズムの解説をしつつ、後半ではGoで実装していこうと思います。 ざっくり書いてみたら量がめちゃめちゃ多かったので、いくつかに分けて投稿しました。 ①仕組み、考え方 <- 今回 ②探索方法 ③Goによる実装 の３部に分かれています。 元論文は An O(NP) Sequence Comparison Algorithm by described by Sun Wu, Udi Manber and Gene Myers です。気になる方はそちらもどうぞ。 最終的な実装を確認したい方は https://github.com/convto/onp に置いてあるのでそちらをごらんください。 これは Makuake Development Team Advent Calendar 2019 - Adventar の4

kubernetes の海の浅瀬に入っていくための資料