並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 117件

新着順 人気順

kayacの検索結果1 - 40 件 / 117件

  • エンジニア in ハイパーカジュアル - KAYAC engineers' blog

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

      エンジニア in ハイパーカジュアル - KAYAC engineers' blog
    • 【JS体操】JavaScript で頭の体操をしよう!〜第一問 44文字 解説編〜 - KAYAC engineers' blog

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

        【JS体操】JavaScript で頭の体操をしよう!〜第一問 44文字 解説編〜 - KAYAC engineers' blog
      • 国立競技場リレーマラソンでサブスリー達成した話 - KAYAC engineers' blog

        こんにちは! マラソン完走で書類選考免除!42.195km採用 の企画に携わっている高田です。 カヤックのエンジニアにはランニングを楽しむ人が多く、SREの藤原や、サブスリーの記録を持つ荒賀、最近記録を伸ばしている千葉などが代表的なランナーです。 社内にはランナーたちが集まるSlackチャンネル「#club-running」があり、日々のランニング活動を共有しあっています。 (#club-runningの活動はこちらの記事をご覧ください) そんなエンジニアたちを中心にチームを組んで「国立競技場 Enjoyリレーマラソン」に出場してきたので、その様子をご紹介します。 完走後の記念撮影。国立競技場は広いですね! 国立競技場Enjoyリレーマラソンの様子 今回はカヤックから3チーム、グループ会社の株式会社カヤックボンドから1チームの合計4チームがエントリーしました。 私たちが参加したのは「フルリ

          国立競技場リレーマラソンでサブスリー達成した話 - KAYAC engineers' blog
        • Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog

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

            Fargate Spotを本番運用するための監視の実践 - KAYAC engineers' blog
          • YAPC::Hiroshima2024に参加の皆様へノベルティなどのご案内 - KAYAC engineers' blog

            カヤック技術部の谷脇です。 さて、2024年2月10日に広島でYAPC::Hiroshima2024が開催されます。カヤックはゴールドスポンサーと椅子スポンサーを行っています。 yapcjapan.org さてそんなカヤックですが、スポンサーノベルティとして今回のために作ったものがあるのでここで紹介させていただきます。 ステッカー御朱印帳 参加者の皆様にお配りするのはこちらです。 ステッカー御朱印帳です。ノートですが、広島にちなんだ柄にしております。また、御朱印帳なので右綴じです。 中身はこんな感じです。 この例のように、他のノベルティで配られるであろうステッカーなどを貼ってスクラップブック風にしてみたり、トークのメモにしてみてください。ちなみにこのステッカーは私が個人的に今回に合わせて作ったものです。こんな感じで会場では自分のシールを配っている人がいることがあります。またシールを持ってな

              YAPC::Hiroshima2024に参加の皆様へノベルティなどのご案内 - KAYAC engineers' blog
            • アンドパッドさんと合同勉強会を開催しました! - KAYAC engineers' blog

              こんにちは。人事部の高田です。 2023年12月4日、株式会社アンドパッドさんと合同で「プロポーザル供養会」を開催しましたので、その様子をご報告します。 プロポーザル供養会 イベントの内容 イベントタイトルは 「プロポーザル供養会」 です。 CNDTとYAPC::Hiroshimaで惜しくもrejectとなってしまったプロポーザルをお披露目する会でした。 発表内容 登壇者とトークテーマは下記の通りでした。 発表者 所属 タイトル fujiwara カヤック 隙間家具 OSS 開発で「自分の庭」をつくる commojun カヤック 長年運用されている Web サービスと通信をするクライアントを Go で作ってみた話 Kyosuke ICHIKAWA カヤック Google Cloud Operations Suite で実現する "頑張らないオブザーバビリティ" muziyoshiz アンド

                アンドパッドさんと合同勉強会を開催しました! - KAYAC engineers' blog
              • NIPPON ITチャリティ駅伝にカヤックから今年は2チーム出た話 2023 - KAYAC engineers' blog

                こんにちは! Tech KAYAC Advent Calendar 2023 2日目を担当する荒賀(@ken39arg)です。 昨年 NIPPON ITチャリティ駅伝 に エンジニア5人のカヤックチームで参加し総合20位でした が、 今年も社内の有志チームで参加してきました。 なんと今年は2チーム+1名の11人で参加してきました!! 平均年齢45歳のおっさんチーム「KAYAC RUN 45」と、若者チーム「KAYAC RUN 30」です。 ちなみに今年も10人中9人がエンジニアで、残りの一人も最近は 42.195km採用 などのエンジニア採用や、社外や面白法人グループなど様々な括りでの合同勉強会を担当している ほぼエンジニアみたいな人 です。 #club-running カヤックのSlackチャンネルである #club-running は2019年に立ち上がり一時はbotしかいない超過疎状

                  NIPPON ITチャリティ駅伝にカヤックから今年は2チーム出た話 2023 - KAYAC engineers' blog
                • primeNumberさんと合同勉強会を開催しました! - KAYAC engineers' blog

                  こんにちは。人事部の高田です。 2023年10月20日、primeNumberさんと合同で勉強会を開催しましたので、その様子をご報告します。 primeNumberさんとは2022年12月にも合同で勉強会を開催させていただきました。 イベントの内容 イベントタイトルは 「組織拡大と共に発生するソフトウェア品質の課題と裏話LT」 です。 簡単に言うと、長期的にサービスやシステムが運用される中で発生する課題や、いわゆる「技術的負債」に関する各社の知見を共有するための会でした。 発表内容 登壇者とトークテーマは下記の通りでした。 発表者 所属 タイトル 鈴木さん primeNumber インシデントの重大度レベル(SEVレベル)策定の話 元木 カヤック Railsでスピード重視で立ち上げたプロダクトの数年後あるある集 中根さん primeNumber 自動化テストをほぼ0 -> 1で社内に浸透さ

                    primeNumberさんと合同勉強会を開催しました! - KAYAC engineers' blog
                  • Google Cloud Operations Suite で実現する "頑張らないオブザーバビリティ" - KAYAC engineers' blog

                    SRE チームの市川恭佑です。 先日、CloudNative Days Tokyo 2023 のプロポーザルを提出したのですが、残念ながら採択に至らなかったので、今回は宇宙最速の(?)供養エントリになります。 シェア・投票など、ご応援をくださった皆様にはこの場でお礼を申し上げます。ありがとうございました。 event.cloudnativedays.jp 背景とか、経緯とか 筆者は、カヤックの SRE チームにちょうど2年ほど在籍しています。とは言っても半年ぐらいは学生アルバイトだったので、正社員としては1年半ほどです。カヤックに入る前も、いくつかの会社で IT エンジニアとしてインターンやアルバイトをしていました。 という訳で、何だかんだ仕事で使うプログラムを書き始めてトータル4年半ほどになりますが、そのうち3年半ほどは全て Amazon Web Services(AWS)でホストされる

                      Google Cloud Operations Suite で実現する "頑張らないオブザーバビリティ" - KAYAC engineers' blog
                    • タスクランナーとしてのmakeを使う際の工夫と注意点 - KAYAC engineers' blog

                      SREチームの長田です。 みなさま開発・運用上の定形オペレーションに伴うタスク実行をどのように管理していますか? 今回は make をタスクランナーとして使う例を紹介します。 タスクランナーがほしい タスクランナーを使う主なモチベーションは以下の2つです。 タスクをリスト化したい タスクの実行インターフェイスを統一したい タスクがリスト化されていれば、それ自体が生きたドキュメントとして機能します。 また、タスクの実行インターフェイスが統一されていれば、 例えばタスクに前処理や後処理を追加したとしても、 開発・運用メンバーが実行するべき操作が変わることはありません。 操作変更の周知コストも下がりますし、変更に伴う操作ミスも減らすことができます。 タスクランナーに求めるもの タスクランナーの機能としては必要最低限のものがよいと考えています。 高機能なタスクランナーも魅力的ではあるのですが、タス

                        タスクランナーとしてのmakeを使う際の工夫と注意点 - KAYAC engineers' blog
                      • 組織拡大と共に発生するソフトウェア品質の課題と裏話LT@目黒 (2023/10/20 18:00〜)

                        お知らせ connpassではさらなる価値のあるデータを提供するため、2024年5月23日(木)を以ちましてイベントサーチAPIの無料での提供の廃止を決定いたしました。 2024年5月23日(木)以降より開始予定の「connpass 有料API」の料金プランにつきましてはこちらをご覧ください。 お知らせ connpassをご利用いただく全ユーザーにおいて健全で円滑なイベントの開催や参加いただけるよう、イベント参加者向け・イベント管理者向けのガイドラインページを公開しました。内容をご理解の上、イベント内での違反行為に対応する参考としていただきますようお願いいたします。

                          組織拡大と共に発生するソフトウェア品質の課題と裏話LT@目黒 (2023/10/20 18:00〜)
                        • OSS 『Prepalert』 の紹介 - KAYAC engineers' blog

                          SREチームの池田です。 この記事が出ている頃には私は SRE Next 2023 に参加しているでしょう。 SRE Next 2023での私のセッションは『Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵』です。 このセッション中で話す仕組みはOSS『Prepalert』というもので実現しているのですが、今回の記事ではセッションの裏番組的にOSS『Prepalert』の紹介をします。 github.com Prepalertについては以前にTechBlog上で記事を書いているので、そことの差分を中心に紹介します。 techblog.kayac.com 3行でまとめ OSS『Prepalert』はMackerel Webhookを受け取って、各所に情報を問い合わせてMackerelのアラートのメモに貼り付ける仕組み そろそろ運用歴2年でv1リ

                            OSS 『Prepalert』 の紹介 - KAYAC engineers' blog
                          • マラソン完走で書類選考免除!42.195km採用

                            ランニングの記録を更新できる人は、エンジニアとしても努力を惜しまず楽しめるはず!?そこで、ランナーがエントリーできる。「42.195km採用」というアイデアを思いつきました。

                              マラソン完走で書類選考免除!42.195km採用
                            • 面白法人グループ合同技術部勉強会を開催しました - KAYAC engineers' blog

                              湿気たちが騒がしい季節となってまいりましたね。みなさまいかがお過ごしでしょうか。カヤック技術部の谷脇です。 先日に面白法人グループの3社、カヤック・カヤックアキバスタジオ・カヤックボンドが集まり、合同で技術部勉強会を開催しましたのでご報告させていただきます。 合同勉強会の趣旨 今回集まった3社には、それぞれ様々な領域のエンジニアが所属しています。今までの技術部勉強会ではカヤック内部に範囲を絞っていましたが、グループに範囲を広げていろんな知見を循環していこうというのが建前です。 実際の趣旨としては「仲良くなる!」です。また、会場は秋葉原のカヤックアキバスタジオおよびカヤックボンドがある秋葉原のオフィスの会議室およびオンラインのハイブリッドスタイルで行いました。カヤックからも秋葉原の現地会場に多数参加しました。実際に顔を合わせて交流できるのは良いですね。 会場の様子 発表内容 勉強会は、それぞ

                                面白法人グループ合同技術部勉強会を開催しました - KAYAC engineers' blog
                              • 【前編】YAPC::Kyoto 2023 におみくじと紙絵馬のブースを出展しました - KAYAC engineers' blog

                                技術部の小池です。 カヤックが協賛した YAPC::Kyoto 2023 にゴールドスポンサーのブース運営スタッフとして参加してきました。 ブース テックカンファレンスにブースを出すのは久しぶりなのでコンテンツをどうするか悩みましたが、鎌倉で京都に挑むぞ!ということでおみくじと紙絵馬を用意することにしました。 おみくじは100枚ほど引いてもらい、絵馬は69枚ほど書いてもらいました。運勢大吉を引いた方も運勢 undef を引いた方も YAPC の思い出のひとつとなっていれば幸いです。会場でお会いしたみなさま、ありがとうございました! 大吉 と undef のおみくじ ほかにも 吉 中吉 小吉 がありました 大吉を引いて喜ぶ fujiwara の様子 #yapcjapan 身内なのに大吉引いてしまった pic.twitter.com/WS6u41WCry— fujiwara (@fujiwar

                                  【前編】YAPC::Kyoto 2023 におみくじと紙絵馬のブースを出展しました - KAYAC engineers' blog
                                • YAPC::Kyoto 2023 にカヤックのエンジニア2名が登壇します! - KAYAC engineers' blog

                                  技術部の長田です。 3/19に京都リサーチパークにて開催されるYAPC::Kyoto 2023に、カヤックからも2名が登壇者として参加することになりました。 yapcjapan.org トーク内容をYAPC::Kyoto 2023公式サイトのタイムテーブルより引用して紹介します。 いずれも普段行っている業務から得られた知見の紹介となっておりますので、これを機にカヤックがどんなことをしているのかを技術的な面から知っていただければ幸いです。 デプロイ今昔物語 〜CGIからサーバーレスまで〜 https://yapcjapan.org/2023kyoto/timetable.html#talk-118 登壇者: macopy 場所: Scrapboxホール by Helpfeel 時間: 15:00〜 みなさま日々Webアプリケーションのデプロイにいそしんでいるかと思います。 デプロイの風景は数

                                    YAPC::Kyoto 2023 にカヤックのエンジニア2名が登壇します! - KAYAC engineers' blog
                                  • 【解説編】CircleCIからOIDCを用いて安全にGoogle Cloudにアクセスする - KAYAC engineers' blog

                                    SREチーム(新卒)の市川恭佑です。これはカヤックSRE連載の2月号です。 よく見ると投稿日が3月になっていますが、どちらかと言うと2月が28日までしかない方に問題があるので、大丈夫です。(何が?) ということで、2023年も滑り出し好調のカヤックSRE連載ですが、前回の記事ではCircleCIからGoogle CloudにOIDCでアクセスする方法について、 ちゃんと動く(はずの)ソースコードをサクッと紹介いたしました。 techblog.kayac.com さて、Google CloudとCircleCIをお使いの皆様、もうOIDC対応は完了しましたか? 安心してください。私のプロジェクトでも一部未完遂です。(おい) ということで今回は、前回紹介したソースコードを深掘りして解説します。 私と同じように、途中でなんか面倒になって一旦塩漬けにしたら正直忘れかけてる長い道のりの途中にいる皆様

                                      【解説編】CircleCIからOIDCを用いて安全にGoogle Cloudにアクセスする - KAYAC engineers' blog
                                    • ゲームにおけるA/Bテストについて - KAYAC engineers' blog

                                      こんにちは。技術部平山です。 今回は、ゲームにおけるA/Bテスト について論じます。 「論じます」で始めたことで察しがつくかとも思いますが、今回はブログではありません。 媒体はブログですが、ブログの容量ではない代物になっております。3.5万字(115KB)超えです。 ゲームにおけるA/Bテストについて、実施の方法や問題点、 倫理的側面に至るまで幅広く書き連ねてみました。 読んで欲しいのはどちらかと言えば同僚なのですが、 そういう時にはまず社外に出してしまった方が良いものですので、 ブログにしてしまいます。 比較的同業の方が読むことを想定しているため、 図表を用いてわかりやすくすることはしておりません。 これを書いた人間は何者か 技術的な問題の前に ゲームにおいても構図は全く同じ A/Bテストが可能である条件 A/Bテストの手続きを概観する 振り分け アプリ内振り分けの場合 Firebase

                                        ゲームにおけるA/Bテストについて - KAYAC engineers' blog
                                      • SRE連載が始まります! - KAYAC engineers' blog

                                        あけましておめでとうございます。SREチーム(新卒)の市川恭佑です。 カヤック技術ブログでは本記事が2023年初エントリですが、Happy Lunar New Year!の方が違和感のない時期になってしまいました。 本年、新たにカヤックSRE連載と題した企画を始めるので、概要についてご報告します。 連載企画を始める経緯 カヤックの技術ブログといえば毎年恒例のアドベントカレンダー企画が人気ですが、これは12月限定のため、それ以外の時期にブログの更新が激減する傾向がありました。 ブログ過疎化の対策として、カヤックでは去年からSREチームで毎月1本のペースでブログ記事を出していました。 実のところ、内部的にはこれを「SRE連載」と読んでいました。 「とりあえずやってみよう」というノリで始まった連載でしたが、結果的には「12月を除くすべての期間において記事を出す」という実績を作れたので、本年は正式

                                          SRE連載が始まります! - KAYAC engineers' blog
                                        • 秘密情報には出どころも書いてくれ!頼む! - KAYAC engineers' blog

                                          SREチームの長田です。 KAYAC Advent Calendar 2022の11日目の記事です。 アプリケーションから何かしらの外部サービスを利用するとき、そのサービスを利用するためのAPI Keyなり秘密鍵なりの秘密情報を保持することになります。 暗号化したものをファイルとしてアプリケーションに持たせたり、 Amazon Web Services(AWS)ならAWS Secrets Managerや AWS Systems ManagerのParameter Store(SSM Paramater Store)に保存したものを実行時に読み込んだりするでしょう。 これらの秘密情報、どこから来たのかわかりますか? どこから来た秘密情報なのか 秘密情報を使って出どころを調べられるのであれば問題はないでしょう。 # 例えばAWSのIAM User Credenntialsとか $ AWS_A

                                            秘密情報には出どころも書いてくれ!頼む! - KAYAC engineers' blog
                                          • アーケード筐体奮闘記~アーケード筐体でPCゲームを遊べるようにした話~ - KAYAC engineers' blog

                                            はじめに この記事はTech KAYAC Advent Calendar 2022の6日目の記事です。 こんにちは、OC事業部その他配属の橋本と申します。普段は専門部隊の手が届かないところにヘルプで入ってよしなにすることを仕事としているのですが、その仕事のうちの一つに「アーケード筐体をPCと繋いでよしなにゲームできるようにしておいて」という無茶ぶり仕事があったので、その時の奮闘を今回ブログとして供養したいと思います。 筐体について 今回動かす筐体はこちらになります。 今回動かす筐体 多分BLASTCITY SEGAのBLAST CITYだと思いますが、僕も細かい仕様はよく知りません。なんせインターネットが発達する前の代物です。しかも非売品。ろくな資料は見つけられませんでした。 さて、コイツの大まかな構成ですが、ものすごくザックリ言うと筐体の中にモニターとコントローラが入っていて、これらをよ

                                              アーケード筐体奮闘記~アーケード筐体でPCゲームを遊べるようにした話~ - KAYAC engineers' blog
                                            • GoでDBを使ったアプリを書くときみんなどうしてる? Tonamelはどうしているか晒してみます - KAYAC engineers' blog

                                              こんにちは。ゲームコミュニティ事業部サーバサイドエンジニアの谷脇です。 この記事はTech KAYAC Advent Calendar 2022の2日目です。 私はTonamelというWebサービスを運営しています。Tonamelでは、GoとPerlを用いてサーバサイドアプリケーションを構築しています。 この記事ではTonamelでのパッケージ構成や、DBを使う際に用いているライブラリについて紹介します。 そもそもTonamelって何 パッケージ構成やは、アプリケーションの特性や、実装の複雑さなども考慮するため、前提として作っているものを説明します。 tonamel.com Tonamelとはeスポーツを始めとした競技の大会を開催するときに用いるプラットフォームです。大会主催者と参加者双方が利用します。 Tonamelの機能説明 この図に挙げているように、『参加者管理』と『トーナメント表』

                                                GoでDBを使ったアプリを書くときみんなどうしてる? Tonamelはどうしているか晒してみます - KAYAC engineers' blog
                                              • ボディビル3位になった話 - KAYAC engineers' blog

                                                こんにちは。長堂 @kzmsngd です。 今回はCalendar for KAYAC | Advent Calendar 2022 - Qiitaの初日の記事として、趣味のボディビルの話をします。 Flutterエンジニア兼ボディビルダーです 実はこのブログに登場するのは3度目です。毎回のようにボディビルに関することを書いています。 技術のことよりボディビルのことを語りたい人間です。 過去に書いた記事: techblog.kayac.com techblog.kayac.com 現在はちいき資本主義事業部でまちのコインを開発しているFlutterエンジニアです。 本格的に筋トレをやり始めて5年目、ボディビルコンテスト挑戦し始めて4年目です。コンテストの成績で言うとこれまでは予選も勝ち残れず結果を出せていませんでした。 「コンテストで結果出せないならそろそろ…」と、コンテスト出場は辞めよう

                                                  ボディビル3位になった話 - KAYAC engineers' blog
                                                • 運用中のサービスに負荷試験を導入した事例の紹介 - KAYAC engineers' blog

                                                  SREチーム(新卒)の市川恭佑です。今回は、Tonamelという自社サービス(Web)において負荷試験を導入した事例を紹介します。 このエントリは「先送りされがちな負荷試験の導入について心理的なハードルを下げる」ことを目的としています。 そのため、事例紹介と銘打っていますが、列挙される事実の独立性よりも文脈性を優先しています。 表現が少し冗長に感じるかもしれませんが、負荷試験について距離感を感じている方は是非お付き合いください。 負荷試験を導入するに至った経緯 Tonamelは、本格的なリリースから5年以上という、比較的長い運用歴を持つサービスです。 まず、何故このタイミングで負荷試験を導入することになったのかについて、その経緯を説明します。 ポストモーテムによる気づき(文化的な土台) 今年の3月に公開されたエントリにもあるように、カヤックでは着実にポストモーテム文化が浸透しつつあります。

                                                    運用中のサービスに負荷試験を導入した事例の紹介 - KAYAC engineers' blog
                                                  • 第二回 PR TIMES x カヤック 合同技術勉強会を開催しました - KAYAC engineers' blog

                                                    SREチームの池田 です 2022年11月11日に、PR TIMES さんとカヤックのエンジニアで、オンライン合同勉強会を開催しました。 この合同勉強会は第2回目の開催となります。1回目はちょうど1年前くらいの2021年11月4日に開催されました。 第1回に関しては以下をご参照ください。 techblog.kayac.com developers.prtimes.jp テーマと発表内容 勉強会の趣旨は第1回と同様でした。 同業他社のエンジニアと知り合う機会を作る 登壇者は特に若手に限らず、募集しました。 今回の裏テーマは『芸術的だなとか、褒められたいとか、偉業だよなとかで、なんかとにかく人に話したい話』になり、話したいことがある人に集まっていただきました。 以下が実際の勉強会のタイムテーブルです。 17:00~17:05 オープニング 17:05~17:15 Rubyサーバアプリケーション

                                                      第二回 PR TIMES x カヤック 合同技術勉強会を開催しました - KAYAC engineers' blog
                                                    • カヤックのSRE伴走支援が『北欧、暮らしの道具店』にもたらしたもの | 面白法人カヤック

                                                      「サービス運用におけるSREの必要性を感じながらも、なかなか手が回らない。」多くの企業が抱える悩みに対して、カヤックはどのような協業や技術的支援を行っているかをレポート。本記事では、カヤックSREチームの藤原、株式会社クラシコムのエンジニア佐々木さまと一緒に、『北欧、暮らしの道具店』へのSRE伴走支援で得られた成果や変化を振り返ります。 佐々木 亮祐 さま(左)株式会社クラシコム /テクノロジーグループ・シニアエンジニア 藤原 俊一郎 (右)面白法人カヤック/技術部・エンジニア、SRE ークラシコムさんが運営する『北欧、暮らしの道具店』ですが、2007年のスタート時はASPのECサービス(カラーミーショップ)から始まり、その後、AWSで自社開発システムを構築していったのだとか。 佐々木 私が2017年にクラシコムに入社した際には、すでに自社開発システムに移行していました。データベースを見る

                                                        カヤックのSRE伴走支援が『北欧、暮らしの道具店』にもたらしたもの | 面白法人カヤック
                                                      • 【dbt小ネタ】 ログの集計 : incremental モデルの実運用 (upsert, リカバリ手法や自動復旧の実現) - KAYAC engineers' blog

                                                        カヤックSREの池田です。 最近、日本のデータエンジニアリング界隈でのdbt(Data build tool)の活用がじわじわと盛り上がってきています。 dbtはpythonのJinjaテンプレートを利用したSQLの拡張を実現し、ETL処理のT(データ変換)に関して強力な機能を提供してくれます。 dbt自体の詳しい説明などは、インターネット上に増えてきていますのでそちらにおまかせするとして、本記事ではdbtを使い慣れてきた人向けの小ネタを話します。 今回は『ログの集計』を例にincrementalモデルを運用する上での問題とその解決方法を紹介します。 www.getdbt.com まずはじめに dbt では モデルと呼ばれる*.sql とスキーマと呼ばれる*.ymlを記述することになります。 例えば、以下のようなsourceのスキーマがあるとします。 models/staging/log/

                                                          【dbt小ネタ】 ログの集計 : incremental モデルの実運用 (upsert, リカバリ手法や自動復旧の実現) - KAYAC engineers' blog
                                                        • Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog

                                                          SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯(ステージング環境を後から立てたり!)から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a

                                                            Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
                                                          • EKSからECSに移行して開発運用コストの削減を図る - KAYAC engineers' blog

                                                            SREチームの長田です。 今回はカヤックで運用している「まちのコイン」というプロダクトのアプリケーション基盤を Amazon EKS(以下EKS)からAmazon ECS(以下ECS)に移行したはなしをします。 まちのコインとは coin.machino.co www.kayac.com まちのコインはカヤックが運営している、デジタル地域通貨を使ってその地域のコミュニティを活性化させるサービスです。 2019年11月から実証実験を開始し、翌年2月から正式リリースされました。 2022年9月現在、20の地域に導入されています。 一般ユーザーが使用するクライアントアプリと、導入地域の運営団体が使用するブラウザ用の管理画面、 それらにAPIを提供するRailsサーバーアプリがあります。 データベースはAmazon Aurora PostgreSQL、 その他AWSのマネージドサービスを組み合わせ

                                                              EKSからECSに移行して開発運用コストの削減を図る - KAYAC engineers' blog
                                                            • カヤック×クラシコム流 事業成長に寄り添うデータ分析基盤のつくり方 | 面白法人カヤック

                                                              2019年から始まった面白法人カヤックと『北欧、暮らしの道具店』を運営する株式会社クラシコムとの協業プロジェクト。持ち前のエンジニアリングリソースやエンジニア採用ノウハウを活用し、伴走型支援を続けてきました。 今回の記事では、データ分析基盤をゼロから構築した軌跡に焦点を当て、クラシコムとの相性を考慮したツール選定の背景や、データエンジニアリングの面白さを担当者に語ってもらいました。 ◆顕在化された、データ分析の環境的な限界 ー最初に、本プロジェクトのきっかけについて伺いたいと思います。もともと、クラシコムさんでは、データ分析はどのような環境で行っていたのですか。 高尾 私が入社した2019年2月当時、クラシコムにはデータ分析チームという存在が特にありませんでした。社内システムのデータが分析しやすい形でMySQLに転送されるという環境はあったので、スプレッドシートに集約して、データを分析して

                                                                カヤック×クラシコム流 事業成長に寄り添うデータ分析基盤のつくり方 | 面白法人カヤック
                                                              • ecrm - Amazon ECRから不要イメージを安全に削除するOSSを作った - KAYAC engineers' blog

                                                                SREチームの藤原です。今回は、AWSのコンテナレジストリであるAmazon ECRから、不要になったコンテナイメージを安全に削除するツールをOSSとして作った話です。 Amazon ECRのライフサイクルポリシーでは、設定によっては実際に利用中のイメージを削除してしまうことがあります 現在利用中のイメージを避けて、それ以外の不要なイメージを安全に削除できるCLIツールをOSSとして作成しました Amazon ECSとECRでのイメージ運用 カヤックでは、コンテナのオーケストレーションにAmazon ECSを主に使用しています。ECSにタスクをデプロイする場合は、イメージのタグにアプリケーションのGitリポジトリのコミットハッシュ(git log -1 --format=%Hで計算した値)を付与してAmazon ECRにpushし、タスク定義ではそのタグを含めたURLを指定しています。 例

                                                                  ecrm - Amazon ECRから不要イメージを安全に削除するOSSを作った - KAYAC engineers' blog
                                                                • 2022年、カヤックは ISUCON 12の出題を担当しています - KAYAC engineers' blog

                                                                  みなさんこんにちは〜! 技術ブログではとてもお久しぶりの acidlemon です。 さて、今年もISUCONの季節がやってきましたね。 ISUCONは、ざっくりいうとLINEが主催する、Webアプリケーションのスピードアップコンテストです。「いい感じにスピードアップコンテスト」なので略してISUCONという感じです。詳しくは 公式サイトを読んでもらうのがよいですが、毎年カヤックもコンテストの参加者だったり出題者だったり優勝者だったりといった形で関わっております。 これまでの開催と、今年の開催はどのような感じになっているかというと… そういえば公開情報をまとめてみた。 過去11回まででISUCONに参加された方は延べ9207名、そのうち優勝経験者は21名。最多優勝は @sugyan @fujiwara の4回でタイ記録。 #ISUCON本 pic.twitter.com/jFFTtUXHn

                                                                    2022年、カヤックは ISUCON 12の出題を担当しています - KAYAC engineers' blog
                                                                  • ステージング環境における検証用データベースの立ち上げを自動化する取り組み - KAYAC engineers' blog

                                                                    SREチーム(新卒)の市川恭佑です。 カヤックのサービスでは、信頼性の担保を目的として、ステージング環境を作成する方針を取っています。 ステージング環境では、検証の精度を高めるために、量・質ともに本番環境に類似したデータベースが求められる局面が頻出します。 そこで今回は、Tonamel という自社サービスにおける、検証用データベースの立ち上げを自動化する取り組みについて紹介します。 サービスの置かれていた状況と解決方針 Tonamel の実行基盤は Amazon Web Services (AWS) 上にあり、本番環境とステージング環境は別のアカウントとして、同一の AWS Organizations 組織内に構築されています。 もともと、ステージング環境では、本番環境のデータは利用せず、手作業でダミーデータを作成していました。 それゆえに、データベースに格納されているデータ量は本番環境と

                                                                      ステージング環境における検証用データベースの立ち上げを自動化する取り組み - KAYAC engineers' blog
                                                                    • カヤック×PR TIMES合同 カヤック社内ISUCONを開催しました - KAYAC engineers' blog

                                                                      カヤックSREの今です。 今年も4月に新卒社員を迎え、4月の後半には技術部研修を行いました。 技術部研修の締めには毎年なにかしらのイベントを行うのが恒例になっており、昨年は社内CTFを開催しました。 今年は、カヤックでは2年ぶりとなる社内ISUCONを開催しました。 新卒のみなさんはオフィスへ集まってもらいました ISUCON1とは Iikanjini Speed Up CONtestの略で、出題されたwebサービスを競技時間内にいい感じにスピードアップするコンテストです。 参加者にはWebサービスが動作する環境と初期実装のソースコード、MySQL等などのソフトウェアの初期設定ファイルが配布されます。 制限時間内でWebサービスの動作が変わらないように変更を加えて、最終的にベンチマーカーが計測するWebサービスのスコアを競います。 Webサービスの構成は問題によって変わります。アプリケーシ

                                                                        カヤック×PR TIMES合同 カヤック社内ISUCONを開催しました - KAYAC engineers' blog
                                                                      • とある相撲ゲーム開発の思い出 - KAYAC engineers' blog

                                                                        こんにちは。技術部平山です。 去年の末、「本格相撲ゲーム(仮)」なるtwitterアカウント が、相撲のようなもののゲーム動画をアップロードしておりましたが、 アレの開発に関わっていたので、そのあたりのお話をしようかと思います。 また、これが後々別の製品の元になっておりまして、そのあたりについても最後に触れます。 なお、ソースコード及びビルドをgithubにて 公開しておりますので、よろしければどうぞ。 ビルドはリリースページにあります。 残念ながら力士モデルやアニメーション、効果音等は購入したもので 再配布できませんので、ソースコードからは削除してあります。 音は鳴らないだけですが、人体モデルがない状態では動きませんので、 代わりにユニティちゃんを入れておきました。 企画の経緯 元々この企画は、社内イベント向けのものです。 「プレゼン対決で勝った企画は72時間の業務時間を使って開発できる

                                                                          とある相撲ゲーム開発の思い出 - KAYAC engineers' blog
                                                                        • 「SRE NEXT 2022」にSREチームの藤原が登壇します - KAYAC engineers' blog

                                                                          SREチームの長田です。 5/14(土)・5/15(日)に開催される「SRE NEXT 2022」にカヤックSREチームの藤原が登壇します。 sre-next.dev 「1年間のポストモーテム運用と、そこから生まれたツールsre-advisor」というタイトルでポストモーテムの運用と、 そこから生まれたツールについて紹介させていただきます。 sre-next.dev カヤックではSREが関わっている社内の複数プロダクトで、ポストモーテムを2020年末から運用してきました。 社内には多数のプロダクトがあるため、エンジニアは自分が関わっているもの以外の事故や事例に疎くなりがちでした。ポストモーテムの運用を通して、それがどう変わっていったかを紹介します。 ポストモーテムからは、普段は問題なく動いていても高負荷時や長期間の運用で問題になる、インフラやミドルウェアの設定が要因として見つかることもあり

                                                                            「SRE NEXT 2022」にSREチームの藤原が登壇します - KAYAC engineers' blog
                                                                          • 既存リソースをTerraformでimportする作業を楽にする - KAYAC engineers' blog

                                                                            SREチームの今です。 カヤックでは、クラウドリソースの管理にはTerraformを利用することが多いです。 クラウドリソースの構成や設定をコードで管理することで、リソースの変更内容の差分をレビューできる、意図しない設定変更を発見できるなどの利点があり、SREの目的であるサービスを安定して提供する上で重要な要素の一つです。 実際の作業として、既に運用中のサービスを新たにTerraform管理下に置く場合や、多くのリソースが既にweb consoleから作成されているものをTerraform管理下に追加する場合も多いと思います。 その際にはTerraform importをする必要があります。しかし、Terraform importは単純作業とはいえ時間と手間がかかり、優先順位を下げてついつい後回しにしてしまうことも多いのではないでしょうか。 今回は、手作業でTerraform import

                                                                              既存リソースをTerraformでimportする作業を楽にする - KAYAC engineers' blog
                                                                            • カヤックのSREチームについて - KAYAC engineers' blog

                                                                              SREチームの長田です。 今回は私が所属している「カヤックのSREチーム」について紹介します。 SREとは Site Reliability Engineering の略です。 「サイト信頼性エンジニアリング」と訳されることが多いようです。 同名の書籍(いわゆるSRE本)が出版されたことから、SREという言葉が一般的に使われるようになったようです。 www.oreilly.co.jp この記事ではSREそのものについての説明は省きます。 ざっくり一言で説明すると、「サイト(サービス)の信頼性を技術の力で担保すること」のようになるでしょうか。 SREの何たるかのより詳しい説明については上記のSRE本や、提唱元であるGoogleのサイト(英語)を参照してください。 sre.google カヤックのSREチーム カヤックのSREチームは2018年に発足しました。 当初は3名体制でしたが、メンバー

                                                                                カヤックのSREチームについて - KAYAC engineers' blog
                                                                              • 突撃!隣のリモートワーク環境 2021 - KAYAC engineers' blog

                                                                                この記事は Tech KAYAC Advent Calendar 2021 の23日目の記事です。 技術部2年目サーバサイドエンジニアのkolukuです。 2年経っても未だにコロナ下にある昨今、去年から引き続きリモートワークを行っている会社も多いのではないでしょうか?自分自身も入社直後からリモートワークで人と接点が無く、時々他の社員はどんなふうに仕事をしているのか思いふけることがあります。 リモートワークといえば、昨年はリモートワークでこう仕事しています!という紹介記事がたくさんありました。それを思い出した自分は社内で「2年かけて熟成されたリモートワーク環境のデスクを見てみたいので、なるべくありのままの状態を見てみたい」という要望で募集したところ、なんと14名も本企画に参加いただけました! エンジニア編 エンジニアのデスクと聞くと「とにかくモニターがいっぱいに並んでいそう」「ガジェットでご

                                                                                  突撃!隣のリモートワーク環境 2021 - KAYAC engineers' blog
                                                                                • 7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog

                                                                                  この記事は Tech KAYAC Advent Calendar 2021 の20日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。今年のTech KAYAC Advent Calendarは3度めの参戦です!よろしくお願いいたします! 本日の記事は、昨年の記事の続きで、Amazon EC2のプロダクトをAmazon ECS構成へと乗り換えた話になります! techblog.kayac.com 目次 目次 背景 Amazon Linuxのサポート終了 ついでにPerlのバージョンもあげた 苦労したポイント 1,デプロイ方法がめっちゃ変わる デプロイのために都度コンテナイメージを焼く 2階建て作戦 2,batchサーバどうするの問題 sqsjfr + SQS + sqsjkr 作戦 3,泥臭い戦い ecspressoの存在 非エンジニアにもわかってもらおう 「

                                                                                    7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog