はてなブックマーク

SREの菅原です。 カンムではAWSやGCP、Datadogなど様々をIaaS・SaaSをterraformで管理しているのですが、以前は「GitHub Actionsでplan」「管理者や開発者が手元でapply」というフローになっており、terraform applyの実行が管理者や一部の権限を持った開発者に集中してしまい、インフラの変更作業の速度が落ちてしまっている状態でした。 しかし、Atlantisという「Pull Request上でterraform plan・applyを実行する」ツールを導入したことで、うまくapply権限を各開発者に委譲することができるようになったので、Atlantisの運用について、特にマルチクラウドへの対応について書きます。 Atlantis www.runatlantis.io AtlantisはWebhookでGitHubのPull Request

エンジニアの佐野です。カンムはバックエンドに PostgreSQL を置きつつサーバを Go で書いています。DB のトランザクションの取り回しは概ね次の様なイディオムになっているのですが、先日 Commit() が漏れている箇所を見つけまして...。結果としてそれについては大きな問題はなく秋の夜長に遅めの肝試しをする程度で済んだのですが、これは事故に繋がるためトランザクションの Commit 漏れ(defer Rollback() 漏れも)を検出する Linter を書きました。 tx, err := db.BeginTx(ctx, nil) if err != nil { return err } defer tx.Rollback() // ... if err := tx.Commit(); err != nil { return err } // ... Linter の方針 次

SREの菅原です。 カンムのサービスのバッチ処理は基本的にEventBridge Scheduler+ECSで動いており、バッチのスケジュールはterraformで以下のように定義されています。 module "kanmu_batch" { # バッチまわりはモジュール化 source = "../modules/batch" for_each = { hogehoge-batch = { schedule_expression = "cron(0 0 * * ? *)" command = ["/batch/bin/hoge", "hikisu"] is_enabled = true } fugafuga-batch = { schedule_expression = "cron(5 0 * * ? *)" command = ["/batch/bin/fuga", "hikisu"]

SREの菅原です。 カンムのサービスはWebサービス・バッチ処理なども含めて基本的にはECS上で動かしているのですが、簡単なバッチ処理はLambda+EventBridge Schedulerの組み合わせで動かすこともあります。 LambdaはECSに比べてDockerイメージのビルドやECRの準備が不要で作成の手間が少ないのですが、terraformでデプロイまで含めて管理しようとすると少し問題がありました。 terraformでのLambdaのデプロイの問題点 例えば以下のような構成のNode.jsのLambdaをデプロイする場合 / ├── lambda.tf └── lambda ├── app.js ├── package-lock.json └── package.json // app.js const util = require("util"); const gis =

エンジニアの佐野です。バンドルカードではポチっとチャージという後払いの機能を利用する際に年齢確認が必須となりました。通信キャリアや銀行との連携等によって年齢確認ができるようになっています*1。今回はこの機能の開発を題材に普段開発でどのようなことを考えて開発し、本機能の開発ではどのようなフローを構築して進めていったかを書きます。 少し概要を書くと、本件についてはウォーターフォールモデル "のような" 開発フローで行いました。事業上の理由でビッグバンリリースが必要でした。要件をしっかり決めてステップバイステップで開発を行いすべての機能を同時にリリースする...案件の性質を考えるとウォーターフォールが開発フローの候補の1つだと思っていたためです。ただそのまま一般的に思われているウォーターフォールを導入するのではなく、その欠点や面倒な点を解消しつつ、認識齟齬なしに設計と実装を行い、納期を死守しつつ

バンドルカードのバックエンドエンジニアをしているshibaです。生粋のiPhoneユーザです。 昨年の10月頃にバンドルカードは Google Pay に対応しました。少し遅くなってしまいましたが、 Google Pay 対応について簡単に紹介したいと思います。なお、 Google Pay というアプリ名は2023年3月頃からGoogle ウォレット に変更され、 Google Pay はGoogle ウォレット 内の1機能という扱いになっています。 Google Pay について まず、 Google Pay や、 Google Pay を使った決済の仕組みについて簡単に紹介します。 まずバンドルカードの説明になりますが、バンドルカードのアプリをインストールし、電話番号を使ってアカウント登録することで、バーチャルカード（オンラインのみで利用できるプリペイドカード）を即時発行することができ

ソフトウェアエンジニアの summerwind です。最近は LLM が自分のふりをして代わりに仕事をしてくれるような仕組み作りを趣味にしています。 先日社内で「ドキュメントをうまく書く方法はありますか？」という質問をもらったのですが、普段ドキュメントを書く時に意識をしている要素のようなものはあるものの、それをちゃんと言語化したことがなかったため、抽象的にしか答えることができませんでした。改めて言語化をしてみるのは面白そうだなと感じたので、今回はドキュメントを書く時に考えていることをいくつか書き出してみたいと思います。 想定する読者を決める ドキュメントを書く時にまず最初にやるのは「そのドキュメントの想定する読者は誰か」についてを考えることです。よくある想定読者には次のような方々がいます。 同じチームで働くエンジニアのメンバー 同じプロジェクトで働くメンバー 全メンバー 想定する読者が決ま

エンジニアの佐野です。カンムはカード決済のサービスを提供しています。カード決済にはいくつかの決済手段があり、マグストライプ、IC、IC非接触(俗に言うタッチ決済)、オンライン決済などの機能が提供可能です。iD のようなスマートデバイスにカード情報を入れてスマホでタッチ決済する仕組みもあります。カンムのプロダクトであるバンドルカードはマグストライプとオンライン決済、Pool はマグストライプとオンライン決済に加えて IC接触決済、IC非接触決済(タッチ決済)を提供しています。今日はセキュリティ的な観点から各種決済手段の特徴や問題点とともに、主に IC 決済の仕組みについて小ネタを交えつつ書いていこうと思います。カンムが提供しているカードは Visa カードでありクローズドな仕様や confidential なものについては言及することはできませんが、公開仕様であったり一般的な事柄のみを用いて

エンジニアの宮原です。 今回はGoでスタックトレースを取得するライブラリ選定についての記事です。 この記事は 【Gophers Talk】スポンサー4社による合同LT & カンファレンス感想戦で発表したものです。 発表スライドはこちらから確認できます。 この記事の目的 この記事ではpkg/errorsからの移行先を探すための参考情報を提供することを目的とします。 Goのエラーハンドリングのやり方等についてこの記事では触れないこととします。 pkg/errors とはなにか pkg/errorsとは、githubのREADMEを引用すると Package errors provides simple error handling primitives. とあり、直訳すると、「エラーハンドリングの基礎を提供するパッケージ」となります。 pkg/errorsを利用することで、Go本体にはないスタ

KanmuでPoolを開発しているhataです。最近、ロボット掃除機を買いました。ロボと猫がじゃれている景色はいいですね。 今回はGoのユニットテストの並行化についての記事です。 TL;DR Goのテストは、並行化することでテスト実行時間の短縮やテスト対象の脆弱性の発見などのメリットがある 基本的にはそのままでも最適化されているが、テストコードにt.parallelを記述することでよりきめ細やかな最適化を施すことができる ただし、一定規模以上のアプリケーションへの導入・運用は大変 テストコードを一気に並行化するtparagenというツールや、並行化忘れを防ぐ静的解析ツールがあり、これらを使うことで無理なくテスト並行化の導入・運用ができる はじめに ユニットテスト並行化とは 本記事では、「並行」「並列」という用語を使用します。本記事におけるこれらの用語を定義します。 並行：複数の処理を独立に

SREの菅原です。 カンムのサービスのバックエンドは基本的にGoで書かれているのですが、一部の内部向け管理画面はPythonのフレームワークDjangoで作成されています。 スタッフがDjango adminページにログインして各種オペレーションを行うのですが、adminページにログインするためにはDjango adminのアカウントが必要です。 社内で使う各種サービスのアカウントは基本的にはAzure Active Directoryを使ったSSOで一元管理されていますが、管理用WebアプリはSAML対応の実装をしておらず、前段のロードバランサー(ALB)でOIDC認証しているものの、adminページ自体のアカウントは管理用Webアプリで追加しなければいけない状態でした。 管理用Webアプリが独自にアカウント管理してしまうと、個別にアカウントを作成する手間が増え、Azure ADでの一元

SREの菅原です。 この記事はカンム Advent Calendar 2022の４日目の記事になります。 少し前にサービスで使っているPostgreSQLをRDSからAuroraに移行しました。 Auroraに移行するため色々と作業を行ったのですが、その中でAuroraの性能を測るために行った負荷テストについて書きます。 pgbench まず最初にpgbenchを使って、単純なワークロードでのRDSをAuroraの性能差を測ってみました。*1 以下がその結果です。 MySQLで同様のテストをmysqlslapを使って行ったことがあって、そのときは概ねAuroraのほうが性能が高かったので、同様の結果になると考えていたのですが、RDSのほうが性能が高い結果になったのは予想外でした。 ただAuroraのアーキテクチャを考えると、pgbenchのような細かすぎるトランザクションの場合はRDSのほ

カンムの achiku です。 2022/11/30に株式会社10Xさま、株式会社CAMPFIREさまと合同で「泥臭くも価値を届ける決済の仕組みと工夫 by 10X + CAMPFIRE + Kanmu」というイベントを開催しました。ご参加いただいたみなさま、ありがとうございました！ kanmu.connpass.com このイベントでは、普及速度が年々加速している「決済」をテーマに、10X・CAMPFIRE・カンムといった決済の中でも異なる役割のプレイヤーが集まり、泥臭くもユーザーに価値を届ける為に行っている現場感たっぷりのエンジニアリングトークをご紹介しました。 セッションに登壇しました 弊社からは hiroakis さんが「バンドルカードのクレジットカード決済システムの泥臭い運用」というタイトルで登壇しました。 speakerdeck.com 国際ブランド決済ネットワークに参加してい

エンジニアの佐野です。今日はインフラの話です。主に物理インフラの話です。カンムがデータセンター(以下、DC)の選定や契約をした際の勘所について書きます。クラウドと DC の相互接続であったりネットワーク構成や機器のコンフィグレーションなどのテクニカルな話はまた別途書こうと思います。 カンムでは主に AWS や GCP 上にインフラを展開して開発を行っています。メインは AWS、機械学習やデータプロセッシングの一部は GCP です。そして先に書いたとおり DC 契約もしています。基本的にはクラウド中心のインフラ運用ですが DC はビジネスパートナーと専用線接続するための重要な拠点となっていて、シンガポール拠点の企業などと専用線で接続しています。DC と AWS 間は AWS Direct Connect で接続しています。 今や特にスタートアップは DC を自前契約することはほとんどないと思

バンドルカードの SRE をしている summerwind です。最近は A Philosophy of Software Design を読んでいます。 タイトルの通り、2022年6月21日からバンドルカードと Pool のカードが 3D セキュアに対応しました。バンドルカードではアプリですぐに発行可能なバーチャルカードを含む全てのカードで対応しているので、気軽により多くの加盟店での決済にご利用いただけるようになりました。 いつもはバンドルカードのインフラやセキュリティといった領域を担当しているのですが、3D セキュアの対応では久しぶりにバックエンドエンジニアとして自分もプロダクト開発に関わったので、今回は 3D セキュアの仕組みとその開発に関する話を簡単に紹介したいと思います。 3D セキュアとは 3D セキュアは、オンラインなど非対面でクレジットカードを使用して決済をする際に、カード

デザイナーの@torimizunoです。 この記事では、バンドルカードでの本人確認改善の取り組みについて、プロジェクトチームの活動の一部をご紹介します。 バンドルカードの本人確認とは バンドルカードの本人確認 バンドルカードのバーチャルカードは本人確認不要で利用を開始できますが、リアル＋カードを発行する場合は利用上限額が上がるため、本人確認手続きが必要になります。 本人確認手続きの詳細はお伝えできないのですが、手続きの一部として、本人確認書類と撮影した本人確認書類と本人情報をご提出いただき、本人であるかの確認を行います。（以降、「本人確認」と呼びます） 確認及び一定の審査が完了すると、カードの発行を行い、お客さまのもとへカードが送られます。 本人確認ができなかった場合は再度申請をお願いすることになり、お客さまのもとへカードが届くのにお時間がかかってしまいます。 本人確認でき発行へ進めたこと

エンジニアの佐野です。最近記事を書いていなかったので小ネタです。先日、菅原企画の社内イベント、エディタについて語る会が催されました。職種にもよりますがカンムでは多くの従業員はオンラインで業務を行っています。たまにはオフラインで交流も...ということで来れる人はオフィスに集まってエディタの話をしつつ軽食を楽しむというコンセプトです。 当日は Vim, Emacs, Visual Studio Code, nano... と様々なエディタのゆるい話から熱い話が語られました。私は Vim の Vim script について話したので今日はそれを記事化します。 0. 私とエディタ 私は長らく Vim をエディタとして使っています。「エディタ」というものを意識したのは大学生の頃でしょうか。機械工学系だったのですがソフトウェア工学や C や C++ がカリキュラムにあり自分もそれらを履修しました。それ

こんにちは、livaです。 カンムでセキュリティエンジニアやってます。入社してから半年程度経った今はPCI DSSの監査準備だったり優先度高めにした施策をOKRに落とし込んで手を動かしたりと慌ただしく動いてます。 初執筆のテックブログでなにを書こうかなと考えていて、3月の末に出たPCI DSSv4がいいかとも思ったんですが、読むだけで一苦労だったので諦めました。あとからゆっくり読みます。 今回はカンムの今と将来のセキュリティ事情を書こうと思います。 入社前の想定 面接や面談時にいくつか課題を聞いていて、大きく2つになるのかなーと考えてました。 1. PCI DSSの運用の課題 カンムはクレジットカードの決済フローでは「イシュア」にあたり、業界のセキュリティ基準であるPCI DSSに準拠している必要があります。これがないとそもそものビジネスが成り立ちません。毎年の準拠が必要なため、最低限のセ

マニアックなSQLに続き2回目の登場、COOの achiku です。 これは カンムでは GitHub Projects (Beta) を利用してプロダクト改善を推進している。Private Betaの時点から使い始めてから約4ヶ月、今の運用に落ち着いてから約2ヶ月程度経過したため、導入の目的、目的を鑑みた運用方法、現時点での状態をまとめる。誰かの参考になれば嬉しい。 ※以降断りのない場合はGitHub ProjectsもしくはProjectsはGitHub Projects (Beta)を指す ※同様に以降断りのない場合はprはGitHub上のPull Requestを指す 前提(2022/03時点) まずは前提の共有から。ぱっと見ても分かるように、小さくはないがとんでもないサイズでもない、という状況のチームの話であるという前提がある。 作っているもの バンドルカード カンム、Visaプ

インフラエンジニアの菅原です。 カンムはサービスの運用にAWSを使用し、そのリソースの管理にterraformを使用しています。 リソースの定義はGitHub上でコードとして管理されているので、何かリソースを追加する場合はプルリクエストを作成してレビューを受けることになるので、運用のポリシーに反するようなリソースの作成はある程度防ぐことができます。 しかしレビューはあくまで人の目によるものなので、チェックが漏れてしまうこともあります。 また「RDSは必ず暗号化すること」などのルールはCIで機械的にチェックして欲しいところです。 そこでカンムではtflintを導入してチェックの自動化を行うようにしました。 TFLintの導入 github.com TFLintはterraform用のlinterで、非推奨な書式に警告を出してくれたり、ベストプラクティスを強制することができたりします。 メジャ

インフラエンジニアの菅原です。 カンムはバンドルカードというVisaプリペイドカードのサービスを提供していますが、Visaと決済情報をやりとりするためにオンプレミスのサーバと通信しています。 カンムのサービスはAWS上で構築されており、AWSとオンプレミスのサーバの通信はAWS Direct Connectを経由してます。 また、ネットワーク制御のためスイッチとしてCisco CatalystとJuniper SRXを使用しています。 ネットワーク機器は通常のサーバと同様になにかしらの問題が発生することがあるため、SNMPによるメトリクスの収集やSNMPトラップでのイベントの検知が必要になります。 また、Syslogはネットワーク機器内にファイルとして保存されていますが、外部にログを転送・保存しておくことで何か問題が発生したときに分析がやりやすくなります。 以前まではEC2インスタンスでS

インフラエンジニアの菅原です。 最近、バイクに念願のグリップヒーターをつけました。 これでツーリング時の手の寒さが多少楽になりそうで喜んでいます。 とはいってもなかなか出かけられないのですが… 現在私はAWS Fargateを使ったサービスをECS上に構築を進めており、日々コンテナと戯れています。 基本的にストレージ以外のコンポーネントはほとんどECSで動いているのですが、VPCのネットワーク内でちょっとした作業（たとえばネットワークの疎通確認など）をしたい場合、都度新しいタスクを起動して作業しています。 また、DBにテストデータを入れたかったり、どうしてもDBを直接操作したいことがある場合、stoneを新しいタスクを起動した上で、そのタスクを踏み台としてaws ssm start-sessionでポートフォワーディングを行い、手元から直接DBにアクセスできるようにしたりしています。 しか

エンジニアの佐野です。Go Conference 2021 Autumn にて Kanmu はスポンサー枠をいただき、オフィスアワーの催しで Go x セキュリティというコンセプトの CTF のような問題を用意させていただきました。 問題はこちら "Go" beyond your proxy になります。 github.com The Go gopher was designed by Renee French. 当日解けなかった人やこのブログを読んで興味が沸いた人もチャレンジしてみてください。 問題を簡単に説明すると、 Go 1.16.4 で書かれたリバースプロキシの背後の HTTP サーバに flag.txt というファイルが置かれています。このファイルには簡単なアクセス制限が施されているのですが、それを突破してそのファイルの中身を参照して解答してください、というものになります。 Go

はじめに こんにちは、カンムでバンドルカードの機械学習部分を担当しているfkubotaです。 今回は、カンムで行っている雑談朝会について書こうと思います。 いきなりですが朝会や雑談会などを普段やっていますか？ コロナの影響でリモートになって「コミュニケーションが足りてない！朝会やるぞ！」という感じではじめた会社、チームは多いのではないでしょうか。 僕も前職含めコロナで失われたコミュニケーションを取り戻したいというモチベーションの朝会に参加していました。 ただこの朝会、とても運用難しいですよね。 勢いよくはじめたものの「この会意味あるの？」 と各人が自問してしまうような会は多くあるはずです。 この記事ではリモートワークで失われてしまった愛すべき雑談を取り戻したいという思いではじめた朝会運用について紹介したいと思います。 僕は朝会は大きく分けて二種類あると考えています。 タスクの共有 コミュニ

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

カンムでCOOをしています、achikuです。 ニッチすぎて誰に話しても「？」となるが、とにかく理解できて嬉しかったSQLの話をする。 誰かにこの感動を伝えたいのでコーヒーカップに向かってクエリの説明している— _achiku (@_achiku) February 21, 2021 話しを簡単にする為にコイントスを用いた例題で説明する。 問題 複数回のコイントスの結果(試行ID、裏が出たか表が出たか、トスした時間)を記録したデータがある。このデータを用いて試行回数t回目において何回連続で表が出たかを出力したい。なお、一度裏が出たら連続で表が出た回数は0にリセットされる。 問題を表で表現する 最終形からイメージすると、大体以下のような事がしたい。試行回数t回目において連続でhead=trueである回数を出す。とにかく時系列に並べた際に時点tにおける連続表が出た回数が欲しい。 consecu

カンムでバンドルカードのバックエンドやインフラを担当している summerwind です。 バンドルカードではスマホ上で Visa のプリペイドカードを発行して決済に使える機能を提供しており、クレジットカード情報を扱っていることから、インフラの観点では高いセキュリティを維持することが重要になっています。バンドルカードのシステムは API や国際カードブランドと接続している決済システムなどの複数のコンポーネントで構成されていますが、システムが構築された時期によって構成や設定の方針などが異なるため、より高いセキュリティを達成するためにシステム構成の変更や整理、設定の見直しを日々進めています。 構成や設定の見直しを進めていく中で、全体的な方針や目指している姿を言語化しておいた方が周囲のエンジニアにも理解が得られやすいのではないかと感じたため、インフラに対する考え方や方針を言語化した「インフラマニ

バックエンドエンジニアの吉田です。カンムでは機械学習を用いた機能開発を担当しています。 バンドルカードでは後払い機能であるポチっとチャージで機械学習が使われています。 去年のAdvent Calendarで石澤さんが カンムを支える技術2020 という記事を書いてくれていましたがそこではあまり触れられていなかった機械学習まわりの取り組みについて簡単にご紹介します。 バンドルカードのサービスはAWSで構築されているので基本的にはAWSに寄せつつも機械学習ではGCPも活用しマルチクラウドで運用しています。 Data Preparation DWHとしてBigQueryを利用しています。BigQueryにはバンドルカードのトランザクションデータやFirebaseで取得したアプリのイベントログ、サーバのアプリケーションログ等が集約されておりデータ分析やA/Bテストの集計、障害調査等に使われています