並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 48件

新着順 人気順

kaminashiの検索結果1 - 40 件 / 48件

kaminashiに関するエントリは48件あります。 aws開発セキュリティ などが関連タグです。 人気エントリには 『AIは励まされると頑張れるらしいので、いろんな方法で奨励してみた。 - カミナシ エンジニアブログ』などがあります。
  • AIは励まされると頑張れるらしいので、いろんな方法で奨励してみた。 - カミナシ エンジニアブログ

    プロローグ 2025/05/22 Claude 4 リリース後、多くの人間が一段階未来へきたと感じていることだろう。 今まで超えられないと感じていた壁を超えたような感覚がある。 dd 更に Claude 4 を、LLMを使いこなしたい。そう思い Claude 4 プロンプトエンジニアリングのベストプラクティスに目を通した。 私の脳に強烈なインパクトを残したのが以下のセクションだった... 面白すぎる...! 本題 どうやら奨励するとAIは頑張れるらしい。 ビジュアル表現が豊かになるらしい。 英語原文だと以下のような内容だ。 For frontend code generation, you can steer Claude 4 models to create complex, detailed, and interactive designs by providing explicit

      AIは励まされると頑張れるらしいので、いろんな方法で奨励してみた。 - カミナシ エンジニアブログ
    • PMとして「顧客解像度」を上げるためにやってること、全部書く|よしおかし・おり🍞

      カミナシでプロダクトマネージャーをやっています、よしおかしおり(@oriori440)です。 「顧客理解を深める」「顧客解像度を上げる」ということは、PMにとって大切なテーマだと思います。 前職でも、顧客解像度を上げるためのユーザーリサーチを積極的に行ってきました。 しかし、カミナシで顧客解像度を上げるのには、苦悩もありました。 本noteでは、そんな私が顧客解像度を上げるために実践してきた具体的な取り組みについて共有します。 この記事が「顧客解像度を上げる」ために悩むPMのヒントになれば嬉しいです。 共感いただけたら、ぜひスキやシェアで教えてください🧡 1. 顧客解像度を"誰よりも"高めることの難しさカミナシのお客様の特性私が今カミナシで向き合っているのは、ノンデスクワーカーと呼ばれる“現場で働く方々”です。 前職までのtoCサービスで私が向き合ってきたユーザーとは異なり、普段会話をす

        PMとして「顧客解像度」を上げるためにやってること、全部書く|よしおかし・おり🍞
      • 良いReactを書くことは凡事徹底だと考えている話 - カミナシ エンジニアブログ

        カミナシで、Webフロントエンドエンジニアをしている osuzu です。 これまでフロントエンド専門外のエンジニアからReactを学ぶ良い方法やお勧めドキュメントを聞かれる度に、 公式ドキュメント のリンクを貼る日々を過ごしてきましたが、何かすごい上達方法がないものかと普段意識していることをこの記事で書き起こしてみました。 文字にした結果、中身になにか特別なことや魔法のテクニックは一つもなく、むしろプログラミング一般に通ずる話ばかりになりましたが、(自戒も込めて)凡事徹底することの難しさもあると感じておりその一助になれば幸いです。 ※ 凡事徹底:平凡なことを非凡なほどに実行すること。一つ一つの理解や実行は平易でも、それを実践し続けるのは難しい。 React Server Component(以下RSC)を採用するかで変わる部分もありますが、記事の例はClient Componentの話が中

          良いReactを書くことは凡事徹底だと考えている話 - カミナシ エンジニアブログ
        • オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ

          こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした(幸いすぐにキャンセルして事なきを得ました)。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確

            オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ
          • 技術的負債になりかけていた機能をリアーキテクティングしたら、めちゃくちゃ改善した話 - カミナシ エンジニアブログ

            ソフトウェアエンジニアの 鈴木 (@szk3) です。 先日、カミナシにおいて古くから存在する1つの機能をリアーキテクティングしました。 その結果、処理時間は4分の1以下、コストは90%程度削減 と大きな成果を出すことができました👏 本記事では、その機能が抱えていた課題に対しどのような改善のアプローチをして上記の結果に結びついたのか?について共有します。 Excel変換とは 今回、リアーキテクティングの対象となった機能は、カミナシに帳票として記録されたデータをExcel形式に変換して出力する機能です。 これを、”Excel変換” と呼んでいます。 Excel変換は、カミナシのサービスの中でも比較的古くから存在する機能です。 ここ数年での利用ユーザーの増加と共に、設計当初のシステムアーキテクチャが技術的な負債となっている状態でした。 Excel変換の課題 まず最初に、設計当初のアーキテクチ

              技術的負債になりかけていた機能をリアーキテクティングしたら、めちゃくちゃ改善した話 - カミナシ エンジニアブログ
            • Amazon S3 へのファイルアップロードで POST Policy を使うと、かゆいところに手が届くかもしれない - カミナシ エンジニアブログ

              はじめに こんにちは。カミナシでソフトウェアエンジニアをしている佐藤です。 みなさんは、アプリケーションのフロントエンドから、Amazon S3 にファイルをアップロードするときに、どのような方法を用いているでしょうか? 「バックエンドのサーバーにファイルを送信し、バックエンドのサーバー経由で S3 にアップロードしている」「Presigned URL を払い出して、フロントエンドから直接 PUT している」など、いくつかの方法があると思います。 弊社で提供しているサービス「カミナシレポート」でも、用途に応じて上記の方法を使い分けて S3 へのファイルのアップロードを行っています。 特に、Presigned URL は、手軽に利用できる上に、バックエンドのサーバーの負荷やレイテンシーの削減といったメリットも大きく、重宝しています。 一方で、その手軽さの反面、アップロードに際して様々な制約を

                Amazon S3 へのファイルアップロードで POST Policy を使うと、かゆいところに手が届くかもしれない - カミナシ エンジニアブログ
              • 助けて! CloudWatch Logs のコストが急上昇!! ログ管理の最適化でコストを 1/3 にした話 - カミナシ エンジニアブログ

                カミナシ ソフトウェアエンジニアの mina(@yoiyoicho)です。このブログでは、私が所属する「カミナシ ID」開発チームにおいて実施した、インフラコストの最適化施策について紹介します! 「カミナシ レポート」の認証機能移行によりインフラコストが増加 「カミナシ ID」は OIDC / OAuth 2.0 などの標準仕様に準拠した、カミナシの ID 管理・認証基盤プロダクトです。インフラは AWS の各種サービスを活用して構築されています。 「カミナシ ID」は認証基盤という性質上、高いセキュリティや監査能力が求められます。そのため、API サーバーのアプリケーションログに加えて、データベースに対する操作やアクセス履歴をすべて記録した監査ログなど、各種ログを詳細に出力しています。これらのログは一度 CloudWatch Logs に集約され、Kinesis Data Firehos

                  助けて! CloudWatch Logs のコストが急上昇!! ログ管理の最適化でコストを 1/3 にした話 - カミナシ エンジニアブログ
                • 監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ

                  こんにちは、新規プロダクトの開発をしています、a2 (@A2hiro_tim )です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開

                    監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ
                  • Terraform で実現する効率的な GitHub 権限管理 - カミナシ エンジニアブログ

                    こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 今月でカミナシに入社してちょうど 1 年が経ちました。前職では 6 年間 SRE チームにいたのでプロダクト開発はブランクがありましたが、さまざまな挑戦をさせてもらっていたらあっという間に 1 年が経っていました。 カミナシのエンジニアリング組織もこの 1 年で急拡大しており、入社当初から比べると正社員のエンジニアも倍以上に増えました。 GitHub の権限管理、どうしていますか? ところで、みなさんが所属されている組織ではどのように GitHub の権限管理を行なっていますか? カミナシではつい先日まで、ほとんどのエンジニアが Organization の Owner 権限を持っていました。理由は、メンターになったエンジニアがニューカマーのユーザーを招待していたからです。 しかし、統制が取れていないことでいく

                      Terraform で実現する効率的な GitHub 権限管理 - カミナシ エンジニアブログ
                    • 理想のフロントエンドテストをたずねて三千里 - カミナシ エンジニアブログ

                      こんにちは。カミナシにて業務委託としてフロントエンドを担当している田村(@junkboy0315)です。皆さんはフロントエンドのテスト、どのように取り組んでいますか?フロントのテストはなかなか難しいですよね。 バックエンドのテストには、「入力、出力、永続化されたデータ」の3つを検証するという基本セオリーがあります。しかし、フロントエンドのテストは、その粒度や手法が多様で、とっつきにくいと感じる方も多いのではないでしょうか。 カミナシでもフロントエンドのテストは以前は十分とは言えない状態でしたが、これまで継続的に改善を重ねてきました。今回は、その変遷についてお話ししようと思います。 夜明け前 カミナシのコードベースでは、元々ユニットテストがある程度整備されていました。これらは主に複雑な計算処理を行い結果を返す関数などに対して実施されていました。 しかし、画面全体の機能を網羅する包括的なテスト

                        理想のフロントエンドテストをたずねて三千里 - カミナシ エンジニアブログ
                      • 円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ

                        こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ(キャッシュ不足に陥るまでの残存期間)を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、

                          円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します - カミナシ エンジニアブログ
                        • RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ

                          こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL 2(MySQL 5.7 互換)を使っています(以下 Aurora MySQL と略します)。 ある日、社内の Slack で「𠮷」などの文字列が登録できないのではないかという話が出ました。これを聞いて「あー」と思った方も多いでしょう。 MySQL で有名な UTF-8 の 4 バイト文字問題で、歴史的な理由から MySQL 5.7 以前では utf8 の文字セットは utf8mb4 ではなく utf8mb3 を指しています。 dev.mysql.com カミナシのアプリケーションは 4 バイトの文字列が入力された場合はシステムエラーを返す実装になっていますが、エラーの内容をユーザーにわかりやすく伝えることは難しいためユーザー体験としても良くない

                            RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ
                          • 属人化とリスクからの脱却! ドメイン & DNS レコード管理をゼロから再設計した話 - カミナシ エンジニアブログ

                            こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。インターネットの根幹を支えるドメインと DNS の仕組みが好きです。 ところで、みなさんの会社ではドメインや DNS レコード(リソースレコード)をどのように管理されていますか? カミナシでは以下のような課題を抱えていました。 運用・管理面 複数のレジストラでドメインが取得されていたため、異なる管理画面の操作方法や請求書の連携で手間がかかっていた DNS レコードのほとんどが手作業で追加され、それらのレコードが登録された経緯や目的の記録が残されていないものが多数あった。加えて、棚卸しの実施が不十分で、必要性が不明確なレコードが多数存在していた セキュリティ面 一部のレジストラにおいては、きめ細やかな権限管理機能が提供されておらず、ID とパスワードを共有せざるを得ない状況であった。結果として、CTO がこれらに関

                              属人化とリスクからの脱却! ドメイン & DNS レコード管理をゼロから再設計した話 - カミナシ エンジニアブログ
                            • AWS WAF を COUNT モードで動かしたはいいが、その後どうすればいいんだっけ? - カミナシ エンジニアブログ

                              どうも Security Engineering の西川です。好きなポケモンはクワッスです。カミナシ社内に遂にポケモンカード部ができまして、部員同士切磋琢磨し始めています。いつか企業対抗ポケモンカード大会をするのが夢です。 さてさて、皆さんは AWS WAF(Web Application Firewall、以下 WAF)を使っていますか?サービスに WAF を導入する際は一定期間 COUNT モードで運用することがセオリーとされています。では、COUNT モードから BLOCK モードに切り替える時に何をもって BLOCK モードへの切り替えを判断していますか? 本記事はつい先日リリースされたカミナシ従業員というサービスを開発しているメンバーから「WAF(Web Application Firewall) を COUNT モードで動かして一定期間経ったのだけど、どのルールを BLOCK

                                AWS WAF を COUNT モードで動かしたはいいが、その後どうすればいいんだっけ? - カミナシ エンジニアブログ
                              • フロントエンドの Monorepo をやめてリポジトリ分割したワケ - カミナシ エンジニアブログ

                                こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシのプロダクトは、管理者の方が使う Web アプリに React、現場の方が使う iPad / iPhone アプリに React Native を採用しています。 どちらもフロントエンドの技術スタックを採用していることもあり、先日までは Monorepo と Yarn Workspaces の構成で運用されていました。 最近では Monorepo 化を進めている事例もよく見かけるようになってきました。 engineering.mercari.com devblog.thebase.in ですが、カミナシでは Monorepo をやめてリポジトリ分割をする意思決定を行いました。 具体的には、harami_client という Monorepo を harami_web と harami_mobile とい

                                  フロントエンドの Monorepo をやめてリポジトリ分割したワケ - カミナシ エンジニアブログ
                                • Web Application のテストを runn で書いて、開発と価値提供を加速する - カミナシ エンジニアブログ

                                  こんにちは、「カミナシ 従業員」サービスチームのソフトウェアエンジニアの a2 (A2hiro_tim) です。 早速ですが、ウェブアプリケーション開発、特に Go 言語を使っている方は、テストをどのように書いていますでしょうか。 我々のチームはバックエンドに Go を採用しており、 Table Driven Test (以下 TDT )を使っていました。Go を採用した開発では TDT が広く採用されており、我々も慣習に則るのが最善だと判断したからです。 しかし実際に開発を進めると、ことウェブアプリケーション開発における TDT にはいくつか課題を感じるようになりました。そこで我々のチームでは runn というツールをテストに活用する方針に切り替え、その結果、開発を加速し、価値提供も早くすることができました。 本記事では、TDT の課題、runn の採用経緯、その後について我々のチームの

                                    Web Application のテストを runn で書いて、開発と価値提供を加速する - カミナシ エンジニアブログ
                                  • JavaScript で Wasm 使ってるなら要注意! そのメモリ、本当に解放されてますか? - カミナシ エンジニアブログ

                                    数ヶ月前、画像処理ライブラリ OpenCV.js を使って Web カメラの映像をリアルタイム処理するプロトタイプを作っていたときのことです。 OpenCV.js は C++ で書かれたコードを WebAssembly(Wasm) にコンパイルして作られており、Wasm ならではのブラウザ上での高速な処理が可能なライブラリです。 実際、画像のフィルタ処理や特徴点検出など、ユニットテストの段階では高速に実行でき、開発は一見順調に進んでいるかのように見えました。 ところが、いざアプリケーションに画像処理モジュールを組み込んでみると、起動したカメラが数秒経つとなぜか止まってしまいました。 コンソールにもエラーは出ず、Chrome を再起動すればまた数秒だけ動く……そんな不可解な状態に悩まされました。 原因は、Wasm のメモリリーク。 そう、恐ろしいことに C++ 製 Wasm で作られたライブ

                                      JavaScript で Wasm 使ってるなら要注意! そのメモリ、本当に解放されてますか? - カミナシ エンジニアブログ
                                    • AWS アクセス管理を一歩先へ!カミナシのセキュアな AWS アクセス管理を実現するシステムの紹介 - カミナシ エンジニアブログ

                                      カミナシのエンジニアリング組織では、チームメンバーの AWS アカウント環境への定常的なアクセス権限として「センシティブな情報を除いた全リソースへの ReadOnly Access」を付与しており、一方で書き込み権限については必要に応じてメンバーが一時的に権限を獲得できる仕組みとシステムを開発し、運用を行っています。 本記事では、そういった仕組みを開発するに至った経緯や仕様、そしてこれを数ヶ月ほど運用した結果と今後の展望について紹介します。 このシステムは『ハマヤン』という名前で呼ばれていますが、あまねくユーザーに愛される素敵な名称であり、Sec Eng チーム内でも大人気です。開発者が濱野さんだからハマヤンにしたのでは?と社内で言われることがありますが、真相は不明です。 ハマヤンを開発した理由 ハマヤン開発前の2022年頃、カミナシではソフトウェアエンジニア全員が Administrat

                                        AWS アクセス管理を一歩先へ!カミナシのセキュアな AWS アクセス管理を実現するシステムの紹介 - カミナシ エンジニアブログ
                                      • Go の ORM はどのようにして AUTO INCREMENT で採番された値を取得しているのか? - MySQL 編 - カミナシ エンジニアブログ

                                        こんにちは。カミナシで「カミナシレポート」の開発を担当しているソフトウェアエンジニアの佐藤です。 カミナシレポートのバックエンドは Go で開発しており、データベースには Amazon Aurora MySQL を使用しています。また、データベースアクセスには ORM ライブラリの GORM を採用しています。 ほとんどのテーブルでは、プライマリキー(ID列)に AUTO INCREMENT を利用しています。これらのテーブルに GORM の Create メソッドなどを使って新しいレコードを挿入すると、AUTO INCREMENT で採番された値が自動的に対応する Struct のフィールドに反映されます。 AUTO INCREMENT による値の採番は MySQL 側で実行されているため、Go 側の Struct のフィールドに反映させるためには、Go アプリケーション側が何らかの方法

                                          Go の ORM はどのようにして AUTO INCREMENT で採番された値を取得しているのか? - MySQL 編 - カミナシ エンジニアブログ
                                        • AWS WAFがあれば安心!? 甘い! 甘すぎる!!「第2回ごーとんカップ」開催 - 次のカミナシセキュリティチャンピオンは誰だ!? - カミナシ エンジニアブログ

                                          初めまして!10 月にカミナシへ入社した いちび(@itiB_S144) です。セキュリティエンジニアリングユニットに所属しつつ、8 月にリリースしたばかりの カミナシ従業員 の開発に携わっています。 先日社内エンジニア向けのセキュリティ競技会「第 2 回ごーとんカップ」を開催しました。ごーとんカップとは、社内のエンジニアが集まって CTF(Capture The Flag) 形式でセキュリティに関する問題、カミナシの開発に関わる問題を一人ひとりが解いて得点を競う大会です。CTFとは、セキュリティなどに関する問題を解いて隠されたキーワード(フラグ)を取得する競技です。 今回は、その運営を担当したので、その様子を紹介します。 ごーとんカップの目的と概要 ごーとんカップはカミナシのエンジニアリング組織におけるセキュリティ文化の醸成を目的としています。カミナシのエンジニア全員参加で、まとまった時

                                            AWS WAFがあれば安心!? 甘い! 甘すぎる!!「第2回ごーとんカップ」開催 - 次のカミナシセキュリティチャンピオンは誰だ!? - カミナシ エンジニアブログ
                                          • 開発チームの中でセキュリティを育てる - セキュリティエンジニア派遣の試み - カミナシ エンジニアブログ

                                            どうもセキュリティエンジニアリングの西川です。JAWS DAYS 2025 の帰路でこのブログを書いています。私は空港でブログを書く確率が非常に高いです。なぜか捗るんですよね。 さて、カミナシでは昨年からセキュリティエンジニアを二人追加で採用することができ、業務委託含め5人体制になりました。それを機にセキュリティエンジニアを開発チームに派遣する仕組みを導入したのでそれについて話をしていきたいと思います。 セキュリティエンジニアを開発チームに派遣するとは 派遣するセキュリティエンジニアの目指すところを一言で表すならば「特定のサービス・プロダクト・チームを深く理解したセキュリティエンジニア」です。 派遣されるセキュリティエンジニアは基本的には最初の半年から1年程度は開発チームの1メンバーとして、ともに開発や運用を行います。ですので、障害対応やインシデント対応、お客様からの通常のお問い合わせなど

                                              開発チームの中でセキュリティを育てる - セキュリティエンジニア派遣の試み - カミナシ エンジニアブログ
                                            • OAuth mTLSを実現するためにAWSでできること、できないこと - カミナシ エンジニアブログ

                                              はじめに カミナシでID管理・認証基盤を開発しているmanaty(@manaty0226)です。 カミナシではAmazon Web Services(AWS)上で認証基盤を構築して動かしています。特にOpenID Providerのコア機能含めて内製しており、さまざまなOAuth拡張仕様を駆使してお客様の要求やプロダクト機能の実現に寄与しています。今回は、相互TLS(mTLS: mutual Transport Layer Security)と呼ばれる、クライアントとサーバーがともに証明書を提示して安全に接続する技術に立脚したRFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens(以下、OAuth mTLSと呼びます)を実現するために検討した内容を書きます。 仕様自体の話

                                                OAuth mTLSを実現するためにAWSでできること、できないこと - カミナシ エンジニアブログ
                                              • スクラムを立て直すために取り組んだ 5 つのこと - カミナシ エンジニアブログ

                                                こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 10 月の終わりに、ひとつだったエンジニアリングチームを分割する形で 2 チームが生まれました。社内では骨 🦴 と稲 🌾 という愛称で呼ばれています。 ちなみに、骨 🦴 の由来はこちらです。 今週から新しいチームが始動するのですが、チーム名は「骨」になりました🦴 英語の "hone" は「磨きをかける」という意味があるので、骨太でしっかりしたシステムを作り磨きをかけるという願を懸けました✨ pic.twitter.com/Gvf2VBYk7d— Manabu Sakai (@manabusakai) 2022年10月25日 前職でチームの立ち上げやスクラムを経験していたこともあり、CTO から骨 🦴 チームのスクラムマスターを任されました(専任ではなくエンジニアと兼任です)。 チームの立ち上げから 1

                                                  スクラムを立て直すために取り組んだ 5 つのこと - カミナシ エンジニアブログ
                                                • 専任チームが存在しないカミナシでどうやってインフラの改善を進めているのか? - カミナシ エンジニアブログ

                                                  こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは職能別のチーム分けをしておらず、エンジニアのロールは基本的に全員ソフトウェアエンジニアです。フロントエンドやバックエンドにとどまらずインフラやセキュリティも含めて、サービス開発チームがすべてを担っています。 CTO の言葉を借りるなら「システムのライフサイクル全体を見る」のがカミナシにおけるソフトウェアエンジニアであり、単一のチームで顧客への価値提供ができる体制を目指しています。 type.jp しかし、個々人のスキルマップを見るとインフラ領域を得意とするメンバーが少なく、インフラの改善は後回しになっていました。 私は前職で 6 年ほど SRE として働いていたので、入社時点からインフラの改善にも着手しなければと感じていました。しかし、専任チームが存在しないカミナシでの取り組みは、まさに試行錯誤の連

                                                    専任チームが存在しないカミナシでどうやってインフラの改善を進めているのか? - カミナシ エンジニアブログ
                                                  • Feature Flags の仕組みを整備して、デプロイとロールアウトの分離を加速させた - カミナシ エンジニアブログ

                                                    こんにちは、カミナシでソフトウェアエンジニアをしている 佐藤 と申します。 弊社で開発・提供しているノンデスクワーカー向けプラットフォーム「カミナシ」(以降「カミナシレポート」や「弊社アプリケーション」と呼びます)において、Feature Flags の仕組みを整備し、デプロイとロールアウトの分離を加速させたことについてご紹介したいと思います。 登場する技術 Amazon Elastic Container Service (ECS) AWS AppConfig AWS AppConfig agent 前提知識 後半の「技術的な話」以降の部分は、以下の技術についても触れています。 Feature Flags、Feature Toggles AWS AppConfig Amazon Elastic Container Service (ECS) Terraform 「背景」や「解決策」といっ

                                                      Feature Flags の仕組みを整備して、デプロイとロールアウトの分離を加速させた - カミナシ エンジニアブログ
                                                    • Goでスタイリッシュにエラーをラップする方法を学んだ - カミナシ エンジニアブログ

                                                      こんにちは。カミナシ ソフトウェアエンジニアの @aoman です。 つい先日、Goで有名な@tenntennさんがConnpassで募集していたGopher塾#2に参加させていただきました。 tenntenn.connpass.com 大変勉強になりおすすめです!筆者が参加したのは第一回目ですが、二回目三回目と予定されているようなので、有料講義ではありますが気になる方はぜひ参加してみてください!学生さんであれば無料の抽選枠もあります。 その際に紹介されていたコードで、エラーのラップ関数があったのですが、これが「メッチャアタマイイ!!スタイリッシュ!!」と感動しました。そのコードは、Goの公式ページである https://go.dev/ のWebサイトを実装しているリポジトリ pkgsite 内の internal/derrors パッケージで実装されています(GitHubリポジトリはミラ

                                                        Goでスタイリッシュにエラーをラップする方法を学んだ - カミナシ エンジニアブログ
                                                      • 【脱PAT】local環境でのプライベートGoモジュールの利用にGitHub Appのデバイスフローが使える - カミナシ エンジニアブログ

                                                        突然ですが、あなたの.netrcや環境変数に、ghp_...から始まる”あの文字列“、そっと忍ばせていませんか? そう、GitHubのPersonal Access Token (PAT) です。 「自分しか使わないから」「有効期限なしが一番ラクだから」しかしその”魔法の文字列”は、開発効率を上げる便利な鍵であると同時に、ひとたび漏洩すれば全てを危険に晒す諸刃の剣。 果たして、この便利で危険な”魔法”を、私たちは本当に封印できるのでしょうか……? local環境でセキュアにプライベートGoモジュールをダウンロードしたい こんにちは。カミナシ認証認可ユニットで共通ID基盤を開発しているminaです。 私たちのチームでも、”便利で危険な魔法”PATに頼らない方法はないか、頭を悩ませた経験がありました。 というのも、私たちは共通ID基盤へのAPIリクエストとサービスのセッション管理を行うことがで

                                                          【脱PAT】local環境でのプライベートGoモジュールの利用にGitHub Appのデバイスフローが使える - カミナシ エンジニアブログ
                                                        • AWSにおける送信者制約付きトークン実現の一検討 - カミナシ エンジニアブログ

                                                          はじめに カミナシでID管理・認証基盤を開発しているmanaty(@manaty0226)です。 以前の記事にて、RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens を利用したクライアントと認可サーバー間のAWSアーキテクチャ構成について考察しました。今回の記事では、以前の記事に基づきクライアントが認可サーバーからアクセストークンを取得したのちに、クライアントがどのように安全にアクセストークンを利用してAPI認可を行うのか検討した内容を書きます。 kaminashi-developer.hatenablog.jp なお、本記事で紹介するAWSの各種仕様は2025年3月3日時点のものであり、今後AWSのアップデートによって変わる可能性があります。 最新の仕様については公

                                                            AWSにおける送信者制約付きトークン実現の一検討 - カミナシ エンジニアブログ
                                                          • フロントエンドから Amazon S3 にマルチパートアップロードしたい - カミナシ エンジニアブログ

                                                            はじめに Presigned URL(*) などで、Amazon S3 へのアップロード処理を実装していると、大きなサイズのファイルをアップロードしようとしたときに、以下のような課題に直面することがあります。 一回のPUT リクエストでアップロードできるサイズの上限が 5GB まで 単一の HTTP リクエストでアップロードするため、大きなサイズをアップロードしようとしたときに問題が起きる。例えば、アップロードの処理の途中で失敗したとき、最初からやり直しになる。 このようなときに活用したいのが、マルチパートアップロードです。マルチパートアップロードとは、その名の通り、アップロード対象のオブジェクトを小分けにしてアップロードする方法です。 AWS の SDK には、マルチパートアップロードが簡単に行えるような API が用意されているものの、多くは、S3 にアップロードを行うことができる I

                                                              フロントエンドから Amazon S3 にマルチパートアップロードしたい - カミナシ エンジニアブログ
                                                            • インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ

                                                              こんにちは。カミナシでソフトウェアエンジニアをしているaomanです。 私のエンジニアとしての経歴はカミナシが2社目で、前職も含めフロントエンドからバックエンドまで一通り開発はしていました。ですが、AWSなどインフラに関しては、アプリケーション開発時必要になったところを少し触ったりするくらいで、ガッツリと本格的に学んだことがありませんでした。 そんな私ですが、今回ECS Clusterの切り替え作業を先輩エンジニア監修の元一緒に行う機会をいただきました。どのようなことをしたのか、簡単にではありますがご紹介させて頂こうと思います! ざっくり概要 カミナシのサービスでは、APIサーバーの運用にAmazon ECS(on Fargate)を利用しています。また、APIサーバーコンテナの他にいくつかのコンテナが起動しています。以下がざっくりとした図になります。1つのTask定義があり、4つのコンテ

                                                                インフラ初心者がゼロダウンタイムでECS clusterの切り替えに挑戦した話〜式年遷宮〜 - カミナシ エンジニアブログ
                                                              • 技術的雑談を生むゆるふわ輪読会のはじめ方 - カミナシ エンジニアブログ

                                                                こんにちは!カミナシでソフトウェアエンジニアをやっているくらさわです! 今回は社内でゆるめに輪読会をやってみた話をブログにしてみました! どうぞご覧ください! 輪読会のきっかけ 読む本の選定について 輪読会の進め方 輪読会の結果と反省 まとめ 輪読会のきっかけ きっかけは僕が最近積読本が増えてきたからなんとかしたいな〜、社内で輪読会でも開いたら無理やり読むようになるかな〜みたいな軽い気持ちで Slack の個人部屋 (いわゆる times ) で呟いたのが始まりでした。 そしたら何人かリアクションくれたので、その場で本の候補を募ってみました。 そんな雑な感じで始めた輪読会ですが、僕の中では二つの目的がありました。 僕の読書習慣をつける 複数チームでまたがって技術的な議論や雑談をする場を作る 1 はかなり自分本位な目的です笑 2 はカミナシでは、少し前にチーム分割により、チームが別れ、雑にチ

                                                                  技術的雑談を生むゆるふわ輪読会のはじめ方 - カミナシ エンジニアブログ
                                                                • Prometheusのメトリックタイプを徹底解説!使い分けでオブザーバビリティを高めよう - カミナシ エンジニアブログ

                                                                  カミナシの認証認可ユニットでソフトウェアエンジニアをしているトモ=ロウです。 早速ですが皆さんPrometheusはご存知ですか? Prometheusは、システムメトリクスの監視に特化したオープンソースのモニタリングシステムです。時系列データを収集・保存し、強力なクエリ言語PromQLを使って分析することで、システムの健全性を詳細に可視化できます。プル型(Prometheusサーバが監視対象のシステムからメトリックをポーリングする形式)を採用している点が特徴的です。 私のチームではPrometheusを使ってメトリクスの収集・分析を行なっています。Prometheusの利用を検討する際に多くの方が最初に感じるのは「メトリックタイプがよく分からん…」ではないでしょうか?少なくとも私はそうでした。公式ドキュメントを読んでも、一部の概念が難解に感じられたり、具体的なユースケースがイメージしづら

                                                                    Prometheusのメトリックタイプを徹底解説!使い分けでオブザーバビリティを高めよう - カミナシ エンジニアブログ
                                                                  • とあるプロダクトのエンジニアチームにKRとしてコード変更行数の変動係数を導入して強いチームを目指した話 - カミナシ エンジニアブログ

                                                                    はじめに こんにちは!社内の「エンジニアブログの更新を絶やさない会」の方から圧を激を貰っている Keeth こと桑原です!現在はEngineering Manager の見習いをしております. 私が所属しているサービスの開発運用に携わるチーム(Eng + PM + PD で構成。以下「サービスチーム」)では,OKR(目標と成果指標)を設定して取り組んでいます.本記事では, KR に盛り込んだ「変動係数」というあまり聞き慣れない指標を導入してみた感想や,その運用方法について振り返りたいと思います.他のエンジニアチームの運用の参考になれば幸いです. ※だいぶ文字文字しい記事になっています どのような KR をたてたのか? 前クォーターでは,サービスチームにおけるエンジニアリングの KR を定め,定期的に振り返りながら達成を目指していました.KRの内容は以下の通りです. 6月末のコード変更差分の

                                                                      とあるプロダクトのエンジニアチームにKRとしてコード変更行数の変動係数を導入して強いチームを目指した話 - カミナシ エンジニアブログ
                                                                    • マルチプロダクトのセキュリティを担保する Production Readiness Check のススメ - カミナシ エンジニアブログ

                                                                      どうもセキュリティエンジニアリングの西川です。禁酒しています。誘惑多い GW を超えたので勝ったも同然です。とはいえ、お酒は飲まずとも酒の場は好きなのでお気軽に誘っていただけると嬉しいです。 さて、今日はカミナシで去年より実施している Production Readiness Check についてお伝えできればと思っています。 Production Readiness Check とは何か プロダクションレディマイクロサービスという書籍が出ています。書籍の紹介に下記のようにあります。 UberのSRE(サイト信頼性エンジニア、サイトリライアビリティエンジニア)として、マイクロサービスの本番対応向上を担当していた著者が、その取り組みから得られた知見をまとめたものです。モノリス(一枚岩)を複数のマイクロサービスに分割した後に、安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンス、監視、ド

                                                                        マルチプロダクトのセキュリティを担保する Production Readiness Check のススメ - カミナシ エンジニアブログ
                                                                      • Fargate Spot が Arm アーキテクチャに対応! シュッと移行してコスト削減を実現 - カミナシ エンジニアブログ

                                                                        こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 「円安を乗り越えるための Arm アーキテクチャへの移行が完了! そのプロセスを公開します」にも書いたとおり、カミナシではほぼすべてのコンピューティングに Arm アーキテクチャを採用しています。また、運用コストを下げるために AWS Fargate を最大限活用しています。 Fargate には Fargate Spot という選択肢があります。 EC2 のスポットインスタンスと同様のコンセプトで、次のような特徴があります。 AWS クラウドの空きキャパシティを活用してタスクを実行 キャパシティが逼迫すると 2 分前の通知とともに停止させられる コストは Fargate と比べて 7 割引(東京リージョンの場合) 高い可用性を求められない環境では Fargate Spot を使ってコストを抑えたいところですが

                                                                          Fargate Spot が Arm アーキテクチャに対応! シュッと移行してコスト削減を実現 - カミナシ エンジニアブログ
                                                                        • カミナシにおけるセキュリティの文化の作り方 - カミナシ エンジニアブログ

                                                                          こんにちは、セキュリティエンジニアリングの西川です。息子が8歳なのですが、生まれてからずっと可愛いままで、いつまでこの可愛さは続いてしまうのでしょうか。 ということで、今日はセキュリティの文化の作り方について話をしていこうと思います。 セキュリティの文化の作り方ってなんなんだろう と言いますか、日々私自身、手探りなのですが、今日は取締役CTOの原トリ(以下トリ)からもらった金言とともにカミナシにおけるセキュリティの文化の作り方について書いていきたいと思います。 カミナシにおけるセキュリティの文化の定義 その前にセキュリティの文化を定義していかなければスタートラインにすら立てないわけですが、カミナシにおいては、セキュリティの問題をセキュリティ担当者の介在なしに、自分たちで気付き、セキュリティの問題をお互い注意し合えるようになるという定義を行っています。これは開発だけではなく、コーポレートでも

                                                                            カミナシにおけるセキュリティの文化の作り方 - カミナシ エンジニアブログ
                                                                          • Object.keys() が返す配列の順序における数値キーの昇順には上限がある - カミナシ エンジニアブログ

                                                                            はじめに こんにちは。昨年の10月にカミナシに入社したソフトウェアエンジニアの tokuse です。 気が付けば入社してから既に半年以上経っており、光陰矢の如しで驚愕しています! カミナシではフロントエンドを TypeScript で開発しています。そんな中、先日 Object.keys() の仕様に起因する不具合が発生し、その際に Object.keys() が返す配列の順序に関する仕様について詳しく知りました。当稿ではその仕様について説明します(ECMAScript 最新前提です)。 はじめに 問題となった処理 Object.keys() の仕様 まとめ 余談 おわりに 問題となった処理 まず、問題となった処理をサンプルコードで紹介します。次のコードは、オブジェクトの数値キーのうち最大値を取得しようとした処理です。 type UserId = number; type User = {

                                                                              Object.keys() が返す配列の順序における数値キーの昇順には上限がある - カミナシ エンジニアブログ
                                                                            • カミナシが顧客に向き合い続けていくためのセキュリティ戦略の考え方 - カミナシ エンジニアブログ

                                                                              どうもセキュリティエンジニアリングの西川です。 暖かい日と寒い日の寒暖差が激しく体がおかしくなりそうですが今のところ健康を維持しております。体もセキュアでありたいものです。 今期のセキュリティ施策の検討 新年を迎え、この半期セキュリティエンジニアリングとして何をやっていくか?を「セキュリティ戦略会議」と銘打ってオフサイトで話し合いました。 そんな目的で始まった話し合いですが、結果的には時間が足りず、どういう方向性でカミナシのセキュリティを高めて行くかというところにとどまりましたが、良い話し合いができたので共有したいと思います。 この話し合いは、CTOのトリ、それからコーポレートITのメンバーと、業務委託としてセキュリティエンジニアリングを支えてくれる濱野さん、そしてこの記事を書いている西川の4名で行いました。 未来からの逆算 今期のセキュリティ施策を考えていく時に、まずは未来にどういう状態

                                                                                カミナシが顧客に向き合い続けていくためのセキュリティ戦略の考え方 - カミナシ エンジニアブログ
                                                                              • 社内で AWS Workshop を開催しました! - カミナシ エンジニアブログ

                                                                                こんにちは。 カミナシでソフトウェアエンジニアをやっている Taku です。 先日、社内で AWS の Workshop を開催してみたところ良い反応をいただいたのでその共有となります。 Workshop 開催の目的 今回 Workshop を開催した主な目的はAWS の自己学習を推進するためです。 カミナシには学習・実験・検証を目的とした「AWS アカウント(検証用個人 AWS アカウント)」を発行して利用できる制度があります。 もっとこの良い制度を活用していきたいという思いと、特に新しく入社した人にはあまり知られていない状態をカイゼンしようと思い、 Workshop を開催することで気軽に AWS を触っていただけるようにしたいと考えました。 Workshop でやったこと Workshop の題材としては、昨年末に参加した AWS re:Invent で体験した以下を利用することとし

                                                                                  社内で AWS Workshop を開催しました! - カミナシ エンジニアブログ
                                                                                • Amazon Aurora の KMS キーをシュッと差し替える - カミナシ エンジニアブログ

                                                                                  こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL を使っています(以下 Aurora と略します)。また、データ保護の追加レイヤーとして KMS を使って DB クラスターを暗号化しています。 docs.aws.amazon.com ここまでは良いのですが、KMS キーに AWS マネージドキーが設定されていました。普段から AWS を使っている方であれば「あちゃ〜」と思われるでしょう。 なぜ Aurora の KMS キーに AWS マネージドキーを使うのが「あちゃ〜」なのか KMS キーには、AWS マネージドキーとカスタマーマネージドキーの 2 種類があります。 AWS マネージドキーはユーザーに代わって作成されるキーで、RDS の場合は aws/rds というエイリアス名が付いています。

                                                                                    Amazon Aurora の KMS キーをシュッと差し替える - カミナシ エンジニアブログ

                                                                                  新着記事