SREチームの長田です。 今回はAWSのVPC(Virtual Private Network)内で作業する時の話です。 VPC内で作業したい VPC内で作業したいこと、ありますよね。 環境構築中の動作確認とか、不具合・障害調査のための定形外作業とか、メンテナンスためのイレギュラーな作業とか。 定常的に行うほどではないですが、AWSでVPCに絡んだサービスを使用しているなら、VPC内での作業は少なからずあると思います。 VPC内に閉じたリソースにアクセスする場合は、当然ですがVPC内からアクセスする必要があります。 VPC外からアクセスするための経路を用意すればそれも可能ですが、アプリケーションが使っている経路とは異なる経路を使うことになるため、 不具合調査時の再現確認などでは余計な要素となることがあります。 VPC内からの操作は、AWSであればCloudShellで VPC環境を作るのが

お久しぶりです。SRE の市川恭佑です。 今回は Go で CLI ツールを作成する際の小ネタを紹介します。 そもそも CLI パーサの選定 Go でコマンドを解析する手法は多岐に渡ります。そもそも標準 flag パッケージだけで実装することも可能ですし、spf13/cobra や urfave/cli をフラグパーサに採用することも多いかと思います。 好きなものを使っていただくのが一番ですが、今回の話題で取り上げる alecthomas/kong は、サブコマンドのサポートのみならず簡単な制約チェックも提供されているのが魅力的です。個人的には、不正なフラグが与えられたときに適切なエラーメッセージを返すことの面倒臭さを考えると、ここら辺もパーサ側にお願いしたいなって気持ちになることが多いです。 ちなみに kong は、alecthomas/kingpin と同じ作者によるツールで、みなさん

SREチームの長田です。 皆さんは操作するAWSアカウントを取り違えたことはありますか？ 私はあります。 カヤックのSREは複数のプロダクトを担当することも多く、 ひとつのプロダクトでも環境(本番、ステージング、開発、etc.)ごとにAWSアカウントを分ける場合があり、 扱わなければならないAWSアカウントが多くなる傾向にあります *1。 今回はうっかり別のアカウントのリソースを削除してしまったーといったオペレーションミスを減らすために個人的に行っている、 「気をつける」以外の対策を紹介します。 間違いに気づくための対策 対象のアカウントが操作の対象として正しいかどうかは、結局は操作している本人にしか分かりません *2。 そのため、「アカウント取り違え自体をなくす」のではなく、 「アカウントを取り違えていることに気づきやすくする」ための対策をしています。 AWSコンソール用の対策 AWSコ

SREチームの長田です。 SREsとしての業務がメインではあるのですが、実はSREチームの人事リソース管理を担当していたりします。 今回はそんな立場から「SRE活動用のリソース」について紹介してみようと思います。 SREなのに「SRE活動用」リソース？ カヤックのSREは、担当プロダクトチームのメンバーとして動く、いわゆるEmbedded SREです。 社内の予算計画の話になってしまうのですが、プロダクトを持つ事業部がSREメンバーのリソース配分を期ごとに確保する形式となっています。 例えばあるメンバーのリソース(100%)のうち、50％分をTonamel(ゲームコミュニティ事業部)に、 30％分をまちのコイン(ちいき資本主義事業部)に割り振った場合、 各割合分のリソースを各プロダクトが属する事業部が負担する形です *1。 Embedded SREの活動とは別に、プロダクトとは直接関係のな

SREチームの長田です。 今回は、カヤックのメンバーが業務で使うために開発・公開しているOSSなプロダクトをまとめて紹介しようという企画です。 KAYAC organization以下にあるものだけでなく、在籍中のメンバーが作ったものもひっくるめて、実際に業務で使用しているものを中心に 紹介しています。 以下の3つのカテゴリに分けて記載しています。 各カテゴリ内はアルファベット順です。 ツール編 人間が手動で実行するもの アプリケーション編 どこかに常駐して、イベントを受け取ると動作するもの ライブラリ編 ツールやアプリケーションから参照されるもの 集めてみたらそこそこの量になったので、本記事では詳細な説明は省いています。 GitHubリポジトリのURLや関連記事のリンクを併記していますので、より詳しく知りたい場合はそちらを参照ください。 (...) 内はそのプロダクトで使用している主なプ

SREチームの藤原です。 今回は CEL(Common Expression Language) を使って、AWSのIAMポリシーを検索するツールを作ったので紹介します。 github.com 3行でまとめ CEL (Common Expression Language)の式を指定してAWS IAMポリシーを検索するツールをOSSとして作りました。GetAccountAuthorizationDetails APIで取得したIAMポリシーをCELで評価して、マッチするものを出力します 例えば「lambda:GetFunctionがあるがlambda:ListTagsがないポリシーを探す」などができます AWSからたびたびやってくる、IAMポリシーに関するお知らせに対応するのに便利です 突然の「Action Required」 ある日、AWSからこんなメールが届きました。 Lambda Ge

こんにちは。技術部平山です。 たぶん15年ぶりくらいに研修の類の講師をやったので、そのことについて書きます。 概要 2D用(github)、 3D用(github) の2つのUnityプロジェクトをテンプレートとして用意して、 そこに「コードだけで」ゲームを作る研修をしました。 どちらも、Hierarchyに何かを足すことは禁止、 足して良いアセットはC#ファイルのみで、 そのC#ファイル内ではUnityEngineの機能を使用禁止、 というレギュレーションです。 いずれも、IMachineなるインターフェイスが存在し、 これを通してゲームを作ります。 例えば2D用のIMachineの主要部分はこんな感じです。 public interface IMachine { public int Width { get; } // スクリーン横解像度 public int Height { get

SREチームの長田です。 今回はssmwrapという拙作CLIツールのはなしです。 ssmwrapとは ssmwrapは、AWS Systems Manager Parameter Store(以下SSM Params)から値を取得し、 環境変数またはファイルに出力した上でコマンドを実行するツールです。 secret類をSSM Paramsに保存している場合、アプリケーション実行時にSSM Paramsから必要な値を取得することになります。 AWSのサービスにアクセスするという操作は、それなりに手間がかかるものですが、 ssmwrapを使えば環境変数とファイルというより簡便な入出力インターフェイスを通してSSM Paramsの値を参照できます。 実装が簡潔になるだけでなく、アプリケーションからのAWS APIへの依存を排除することにもなります。 # SSM Paramsにこんな値が保存され

こんにちは！ カヤック面白プロデュース事業部のおばらです。 普段は受託案件のデザイン・フロントエンド開発などを担当しています。 さて、『JS体操』第2問 いかがでしたか？ 今回初めての方々 第1問に引き続きの方々 複数のアプローチで何通りも回答してくださった方々 普段業務で JavaScript をバリバリ書いているであろう方々 JavaScript を学んでいる学生の方々 などたくさんの方々が挑戦してくださいました。 とても嬉しいです。ありがとうございます！ 『JS体操』とは？ 『JS体操』とはカヤックが主催する JavaScript のコードゴルフ大会です。 もともとは社内の勉強会として始めた施策です。 その詳細は以下のブログ記事を御覧ください！ techblog.kayac.com 第2問の詳細はこちら https://hubspot.kayac.com/js-taiso-002 も

SREチームの池田(@mashiike)です。SRE連載の５月号になります。 AWSのコストについては、多くの方がすごく気にしていると思います。 カヤックでもAWSのコストの変動に関しては敏感に気にしています。 そんな方々の心のお供になる機能が、 AWSコスト異常検知(AWS Cost Anomaly Detection) です。 今回は、このコスト異常検知にまつわるトイル削減の取り組みを紹介します。 背景 AWSコスト異常検知は、AWS マネジメントコンソールの中では『Billing and Cost Management』配下にある機能になります。 この機能を使うことでAWSで発生したコストに関して、通常とは異なるコストの発生を検知することができます。 コスト異常検知自体については、CureApp テックブログ様のZennの記事がわかりやすくまとまっているので、そちらを参照いただければ

こんにちは。技術部平山です。 今回は、ハイパーカジュアルというジャンルにおけるエンジニア、 というテーマで書きます。 勉強会でしゃべった動画がありますので、そちらを見て頂いても良いかと思います。 外に出すということで、普段よりも多少丁寧にしゃべっております。 前置き 平山が作った製品群 これらは2022年あたりから現在にかけて、平山が自分で企画、実装した製品です。 これらのうち、利益を出せた製品は2つあります。 黒字製品 Draw Saber(Android iOS) Mannequin Downhill(Android iOS) の2つで、順に2800万、2100万ダウンロードです。加えて、いい線まで行ったものの、利益を出すに至らなかった製品が一つあります。 赤字だったTitanShoot Titan Shoot(Android iOS) こちらは210万ダウンロードと、うまく行ったもの

こんにちは！カヤック面白プロデュース事業部のおばらです。 普段は受託案件、特にインタラクティブな WebGL や Canvas2D を駆使する案件のデザイン＆実装を担当しています。 先日出題したJS体操 第1問目、挑戦してくださったみなさまありがとうございました！ 早速ですが最短文字数の回答は 44文字 でした！ export default x=>x-(x%=.2)+.2-(.04-x*x)**.5 みごと44文字を達成した方は、 halwhite さん koyama41 さん sugyan さん tkihira さん たつけん さん の5名！（※ Unicode コードポイント順） おめでとうございます！！ 最短文字数を狙った正統派の回答以外にも、裏技的な面白アプローチがたくさんありました笑 このアプローチは面白い、ぜひ紹介したい！という回答がいくつかあったので、解説記事は2回に分けて

SREチームの橋本です。SRE連載の3月号となります。 Amazon ECSのコスト最適化においてはFargate Spotが有効な手段となりますが、いつ中断されるか分からない性質上、その監視も併せて実施していく必要があります。今回はそのFargate Spotを本番環境で運用しているプロジェクトにおける取り組みを紹介します。 背景 Fargate (Amazon ECS on AWS Fargate) を用いると負荷に合わせた容易なスケーリングが可能になる一方、このときCPU使用率の安全マージンや予測のブレなどにより、リソースがやや過剰になってしまうこともあります。 Fargate Spotの代表的なユースケースと言えばユーザーに露出しない開発環境ではないかと思いますが、このような場合にコストを考えると、タスクの中断をある程度許容しての本番環境でのFargate Spot運用も可能な選択

こんにちは、技術部の谷脇です。 去る2月10日に行われたYAPC::Hiroshima2024ですが、みなさまはいかがだったでしょうか。私は参加して大満足であり、運営の方々に大感謝させていただきます。 さて、カヤックではゴールドスポンサーと椅子スポンサーをしていたというのは開催直前に出した記事で述べさせていただきました。 techblog.kayac.com この記事では伏せられていた、椅子スポンサーのPerlbatrossですが、この記事ではPerlbatrossの内容紹介と問題解説をしようと思います。 Perlbatrossとは YAPC::Hiroshima2024の開催期間中にコードゴルフの問題を出していました。以下は椅子スポンサーで貼らせていただいた問題です。 Q1. Split of Graphemeの問題 さて、これだけではなく、QRコードにアクセスすると実際に問題を解けるサ

SREチームの藤原です。 今回は Amazon CloudFront Functions をテストするためのOSSとして、cfft というものを書いたので紹介します。 github.com 3行でまとめ CloudFront Functionsのテストは手元ではできなくて面倒です CloudFront Functionsをテストする cfft というOSSを書きました KeyValueStoreの操作を含め、便利な使い方がいろいろありますのでどうぞご利用下さい CloudFront Functionsをテストするのが面倒という問題 CloudFront Functions (以下CFF) は、AWSが提供するCDNであるAmazon CloudFrontのエッジノード上でリクエストやレスポンスの操作が行える、JavaScriptの実行環境です。典型的なユースケースとしては、キャッシュキーの

SREチームの長田です。 SRE関連の記事としては今年最初の記事になります。 今年も定期的にSREチームメンバーによる記事を投稿していく予定です。 よろしくお願いします。 さて、今回はGitHub Actionsのはなしです。 TL;DR デプロイを実行するGitHub Actionsの実行状況を デプロイ対象環境ごとに別々のSlackチャンネルに通知する場合の実装例として、 「slackapi/slack-github-actionで通知をつくりこむ」 「Actions Workflowを分ける」 「Actions Workflow実行の入り口を分ける」 の3つを紹介します。 背景 カヤックでは「まちのコイン」という地域通貨サービスを開発・運用しています。 coin.machino.co まちのコインの開発・運用チームの、特にサーバーサイドに関しては、 アプリケーションやインフラ構成の変

このエントリは【カヤック】面白法人グループ Advent Calendar 2023 の24日目の記事です。 こんにちは！意匠部のおばらです。 面白法人カヤックでは日々、様々な社内勉強会が開催されています。本記事では JS 好きな社内のエンジニア向けに私が企画＆主催している「JS体操」についてご紹介します。 記事の最後にはみなさんも挑戦できるように最新の「JS体操」を紹介しています。ぜひ挑戦してみてください。 1.「JS体操」とは？ 2.「JS体操」の掟 3.「JS体操」のメニュー 3.1. 何らかのロジックを解く 3.2. コードゴルフで文字数を競う 4.「JS体操」の流れ 4.1. 出題方法 4.2. 解答方法 4.3. 実際の様子 5.「JS体操」の過去問の紹介 5.1. 第一回 5.2. 第二回 5.3. 第三回 5.4. 第八回 5.5. 第十一回 5.6. 第十四回 5.7.

この記事はTech KAYAC Advent Calendar 2023の7日目の記事です。 こんにちは、@commojunです。記事を書くのは２年ぶりです。昨年は娘が生まれ、最近1歳になりました。知らない間に紙を食ったりしていて、目が離せません！！ はじめに 皆さんはご自宅にプリンターはお持ちでしょうか？我が家にはあります。ペーパーレス化が進んできた昨今、プリンターを持たないという人も増えてきていると聞きます。たまにしか印刷しないならコンビニで大丈夫だったりしますからね。 しかし、印刷物が必要になる出来事は突然やってきます。最近だと、保育園の入園申し込みをするために、市で公開されているPDFファイルを紙に印刷して、期日までに申し込み用紙を完成させる必要がありました。そんなときプリンターでさくっと申込用紙を出力できると頼もしいです。内容を書き損じたときも、気軽にもう一度プリントするだけです

Tech KAYAC Advent Calendar 2023 の11日目です。 こんにちは。 専らドッグフードを食べる側の長田です。 もちろんリアルな犬のはなしではなく、ドッグフーディングのはなしです。 https://ja.wikipedia.org/wiki/ドッグフーディング ドッグフーディング (英: dogfooding) または「自社のドッグフードを食べる」「ドッグフードする」(Eating your own dog food、Drinking your own champagneとも言う)は、コンピュータ業界において、自社製品を開発して利用する組織の習慣で、組織が実際の使用法で日々自分たちで製品を利用しながら製品テストを行うことである。 カヤック由来のOSS 実はカヤック(社員名義も含む)はOSSなプロダクトをそこそこの数公開しておりまして、実際の業務でも使っています *1

こんにちは！ Tech KAYAC Advent Calendar 2023 11日目を担当する荒賀(@ken39arg)です。 在籍期間15年と弊社の中でかなり古参になってしまった私ですが、アドベントカレンダーを年に2本書くのは初めてです。1 今回の内容は、今年7月に無事に成功したお仕事の話で、完了したらブログに書くように言われていたものです。 が、どうしても筆が進まず、のらりくらりと逃げていたのですが、良い年越しをするためにいい加減書いておくか〜という内容です。 TL;DR Rails + PostgreSQL + Apartment という構成のサービスで下記の1行の設定変更コミットを取り込んだ結果・・・ $ git log -n1 -p 64b39f258e9adde2e55752e4f1d5b6be12bcb216 commit 64b39f258e9adde2e55752e4f