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

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

どうもセキュリティエンジニアリングの西川です。 先日、株式会社Flatt Security のCCO豊田さんにお誘いいただき、カミナシのセキュリティの取り組みや開発生産性をどのように考えているかをファインディ株式会社主催の開発生産性Conference 2024 にてお話させていただきました。 当日の資料は下記です。 speakerdeck.com ※自動でライトがつく OR 無灯火を知らせるのページで左側の運転手が寝ていますがそれに意味はありません どういうことを話したか ざっくりですが、下記のような話をしました カミナシのサービスのセキュリティのオーナーシップは開発者が持っている セキュリティエンジニアリングはイネーブルメントの役割を担っている どうして Flatt Security 社の脆弱性診断を選んだか セキュリティは力を持っているからこそ生産性を奪いかねない ところで、セキュリ

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

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

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

どうもこんにちは西川です。AWS Community Builder に選ばれたからにはAWSのこともアウトプットしなきゃということで、今日は Security Hub の Central configurationの素晴らしさをお伝えしたいと思います。 Security Hub 運用の課題と Central configuration Cental configuration は re:Invent 2023 で発表された機能で、実は最近までこの機能が追加されていたことに西川は気づいておりませんでした（汗） でも、この機能はSecurity Hubを運用していくうえでは欠かせない機能で、それはなぜかというと、Automation rules では、OU単位だったり、アカウントについているタグ等を判別してルールを書くことができないのですが、AWSアカウントをOrganization管理して

こんにちは！ カミナシでエンジニアリングマネージャーとして働いております、吉永です。 先日、 3/21 に Findy さんが主催の「TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜」というイベントに参加してきました。 findy.connpass.com イベントにブログライティング枠なるものがあったので、この枠での参加ではないものの、参加レポートを書いてみます。 動機 mtx2s さんの記事は以前から参考にさせていただくことが多くて、毎回首がもげそうになるくらいの共感や学びを得られていました。自分自身のマネジメントの参考にもしています。いつかお会いしてみたいものだなと思っていたところ、偶然このイベントが開催されることを知り、すぐに参加を決意した次第でした。 イベントのテーマも今の私にうってつけのものでした。私の担当するチームが提供するサービスは20

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

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

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

こんにちは、カミナシのソフトウェアエンジニアの内田 (@A2hiro_tim) です。 11/28、AWS の CEO Adam Selipsky 氏の Keynoteで Amazon Q が発表されましたね。 今回ありがたいことに、AWS re:Invent 2023 にラスベガス現地で参加する機会をいただき、複数のセッションに加え、この Keynote も聞いてきました。 Amazon Q についての情報はまだ多くないですが、Amazon Q の中でも、"Amazon Q for general business use" と呼ばれる機能について、現地のセッションで聞いた話が面白かったので、書いてみたいと思います。 Keynote の様子 私は大学院で機械学習の研究室に所属していて、同時期に AI コンサルティングの会社でインターンもしていました。卒業後はソフトウェアエンジニアとしてキ

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

どうもセキュリティエンジニアリングの西川です。 12/3(UTC)現在まだラスベガスにいます。これが今回のラスベガスで書く最後のブログとなります。 最高の仲間たちと過ごせて最高の1週間でした。笑いすぎてお腹が筋肉痛です。 たくさんのお土産話ができましたので、日本に帰った際は聞いていただけると嬉しいです。 ラスベガス最後は「セキュリティの自動化」について話をしていきたいと思います。セキュリティの自動化といってもAWS環境の話で、コンプライアンス違反があったら自動的に修復したりするもののことを言っています。 どうしてこうも世の中、「セキュリティの自動化」の話が多いのだろうと思いながら色々なセッションを聞いていました。そして、「セキュリティの自動化は本当に必要なのだろうか？」と、ここラスベガスで自分の中であれやこれやと考えていて、最終日に「SEC327-R1: Speed up cloud se

ソフトウェアエンジニアの鈴木(@szk3)です。この記事は re:Invent の現地 ラスベガス からお届けしています。 唐突ですが、re:Invent 2023 にて行われた AWS GameDay Championships 2023 というグローバルな舞台で優勝🥇することができました ＼ やったー 🙌 ／ ということで 本記事では、現地でGameDayに参加する際の知見をシェアしたいと思います。 本文に行く前に最初にお伝えしておくと、GameDayに参加する誓約としてゲーム内容の共有は禁止されていますので、どんなゲームだったのかについては触れませんのでご了承ください。 この記事が、今後 ラスベガスでGameDayに参加してみたい！と思っている方の参考になれば幸いです。 ではでは、早速いってみよー AWS GameDay とは まずは、そもそもGameDayとは何なのか？について

AWS re:Invent 参加中のソフトウェアエンジニアの内田（@A2hiro_tim）です。 “Build and scale generative AI applications with Amazon Bedrock” という Workshop Session に参加しました。 Workshop Session は、まず簡単に Amazon Bedrock の概要を10分ほど話して、そこから用意された 資料の説明に沿ってひたすら進める形式でした。資料はおおまかに以下の構成です。 簡単な Prompt Engineering をやってみる Email 生成アプリを使ってみる 後半の資料とコードは既に公開されています。興味ある方は試してみてください。 資料：workshop studio コード：Github: build-scale-generative-ai-application

ソフトウェアエンジニアの鈴木(@szk3)です。AWS re:Invent 2023に参加しており、現地ラスベガスでこの記事を書いています。 さて、本日の Keynoteで発表された Amazon Q という生成AIのサービスですが、めちゃくちゃ使えそうという印象を受けました。 aws.amazon.com しかし、そんな Amazon Q ですが、公式サイトの紹介ページヘッダーを見ると、専門領域と機能の複数の切り口で紹介されており、若干わかりづらい感じになっています。 専門領域のところでいうと、Amazon Qが主となる「Amazon Q (For Business Use)」「Amazon Q (For AWS Builder Use)」の２つで、他のAWSサービスにbuilt-inされる「Amazon Q in QuickSite」「Amazon Q in Connect」「Amaz

こんにちは、セキュリティエンジニアリングの西川です。 WAFのワークショップ（NET308-R1 | Get hands-on with fraud prevention using AWS WAF ）に参加し、面白い機能がAWS WAFに追加されていたので、そちらを紹介します。 なお、ここではAWS WAFの説明は割愛します。 今日ご紹介したいのはApplication integrationという新機能です。 画像の左側をみていただくとわかる通りNewのアイコンが出ていますね。 Application integrationでは、アカウントへの不正アクセスを防止するための機能で、ログインページで用いられます。 機能としては二つあって、一つ目がInteligent threat integration、もう一つがCAPTCHA integrationです。CAPTCHAはみなさんご存知の

おはようございます（？）セキュリティエンジニアリングの西川です。 AWS re:Invent 2023 2本目の記事です。前回同様、若干ガバナンス系の話なのですが、 「SEC319-R | Enhance cloud security: Using AWS SRA with Terraform」というセッションを聞いていました。 このセッションではChalk talk というセッション形式で、SRA（Security Reference Architecture）の概念やこういう風に適用していくといいよという話をスピーカーがしながら、参加者は適宜質問をするという形式のもので、スピーカーの方から「これは対話形式なので質問があれば挙手をお願いします」と伝えていました。 SRAという言葉はまだあまり聴きなれない方も多いかもしれませんが、2021年あたりから出てきたもので、CIS Critical

こんばんは（？）、セキュリティエンジニアリングの西川です。 re:Invent始まりましたね。 カミナシからも今年は4名参加して、AWSの知識・技術向上のためさまざまなセッションに参加しています。 私は今回re:Inventは初参加で、右も左もわからない状態ですが、その中でも特に楽しみにしていたセッションがありまして、それが「COP402: Coding for compliance at scale」でした。 このセッションはレベルが400（Expert）という一番高いものでしたが、コードを見ながら解説がされていくため元々開発者だった私にとっては非常にわかりやすかったのと、 RDK（AWS Config Rule Development Kit）を試そうとして色々と調べていたので、英語はあまり得意ではないのですが理解することができました。 AWS Configのカスタムルールが書けるのは