【Next.js】SWRとaspidaでフロントエンドのデータ取得部分を改善した話 - KAYAC engineers' blog
こんにちは、ちいき資本主義事業部でフロントエンドエンジニアをしている片岡です。 この記事ではカヤックが開発している「まちのコイン」の管理ダッシュボードで、APIサーバからのデータ取得部分の改善したことについて紹介します。 まちのコインについては、以下のURLをご覧ください。 coin.machino.co 管理ダッシュボードについて dev環境のダッシュボードのスクリーンショット画像 管理ダッシュボードは、まちのコインが導入されている地域の運営団体の方が主に利用します。ダッシュボードには、統計情報の確認やお知らせの配信、まちのコインの体験を作成できる機能があります。 管理ダッシュボード開発の課題 ダッシュボードは、Next.js(React)で開発をしていて状態管理ライブラリはRecoilを採用しています。 ReactコンポーネントでAPIを叩いてデータ取得をする場合は、React Hoo
【解説編】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
SREチーム(新卒)の市川恭佑です。これはカヤックSRE連載の1月号です。 みなさんの記憶に新しいと思いますが、先日CircleCIで大きなセキュリティインシデントがありました1。 このインシデントを受けて、環境変数やContextに保存された外部サービスへの認証情報を更新しながら「自分もOIDC対応しておけば......」と後悔した方も少なくないと思います。 外部サービスの例として、Amazon Web Services (AWS)に関しては、公式OrbにてOIDC連携がサポートされていたり、AWS側のIdentity and Access Management (IAM)設定を含む情報がインターネット上に数多く公開されています。 ゆえに、CircleCIのパイプラインからAWSにアクセスする箇所について、OIDC連携に対応する難易度は比較的低いです。 これに対して、Google Clo
SRE連載が始まります！ - KAYAC engineers' blog
あけましておめでとうございます。SREチーム(新卒)の市川恭佑です。 カヤック技術ブログでは本記事が2023年初エントリですが、Happy Lunar New Year!の方が違和感のない時期になってしまいました。 本年、新たにカヤックSRE連載と題した企画を始めるので、概要についてご報告します。 連載企画を始める経緯 カヤックの技術ブログといえば毎年恒例のアドベントカレンダー企画が人気ですが、これは12月限定のため、それ以外の時期にブログの更新が激減する傾向がありました。 ブログ過疎化の対策として、カヤックでは去年からSREチームで毎月1本のペースでブログ記事を出していました。 実のところ、内部的にはこれを「SRE連載」と読んでいました。 「とりあえずやってみよう」というノリで始まった連載でしたが、結果的には「12月を除くすべての期間において記事を出す」という実績を作れたので、本年は正式
GoとテストとSDKとGCP - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。これはKAYAC Advent Calendar 2022の9日目の記事です。 今年の弊社アドベントカレンダーは、筋肉やランニング、さらにはサウナなど、多様性に富んだ面白いエントリが出揃っています。 自分も好きなファッションについて書きたくなってしまったのですが、ここはグッと気持ちを抑えて、仕事で触った技術について書きます。 ※ この記事のタイトルは、酒とゲームとインフラとGCPというイベントのオマージュです。 仕事の近況報告 まず、最近どんな仕事をしているのかについて報告させてください。恐らく誰も興味がないと思いますが、年末のアドベントカレンダー企画ということもあるので...... Amazon Web Services(AWS)を用いた自社サービス 今年の4月に新卒入社してから、技術ブログを2本執筆しました。下記がそのリンクです。 techblog.
【圧倒的快感】2022年に行って良かったサウナランキング - KAYAC engineers' blog
この記事は 面白法人グループ Advent Calendar 2022 の7日目の記事です。 アウフグース 「最近サウナ流行ってるけど別に興味ないや。」 「そもそもサウナとエンジニアって関係なくない？」 ちょっと待ってください！！ サウナとエンジニアは一見関係なさそうに見えますが、実はかなり深い因果関係があるのです！！！ エンジニアは頭を使うので脳に疲れが溜まってしまいがちです。 そして、疲れが溜まると仕事のパフォーマンスが落ちてしまいますね。 しかし、サウナに行くと脳の疲れが綺麗さっぱりなくなります！ しかも疲れている時の方が気持ちよくなれるのです！！！ そうなんです！ エンジニアとサウナには究極の因果関係が存在するのです！！！ 仕事で頭を使うので脳が疲れる → 疲れているからサウナで深く整える → 脳の疲れが取れて仕事で良いパフォーマンスを発揮できる → 仕事で頭を使うので脳が疲れる
Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯（ステージング環境を後から立てたり！）から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a
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を指定しています。 例
SLI/SLO運用の実践 shimesabaによる指標モニタリング - KAYAC engineers' blog
カヤックSREの池田です。 先月は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール『shimesaba』の話をしました。 techblog.kayac.com github.com 今回は、実際にどのようにSLI/SLOを運用しているのか？という内容をshimesabaを使った設定例を交えつつ話します。 SLI/SLOの運用にお悩みの方の助けになれば幸いです。 最初のSLI/SLOはどう決定したのか？ SLI/SLOの運用を始めるにあたって、多くの人が悩むのは以下の２つだと思います。 一体何をSLIとすれば良いのか？ 最初のSLOはどのくらいにしたら良いのか？ つまりは、最初の1歩をどうしたら良いか？と言う話ですが、こちらに関しては２つ参考になるものがあります。 『SLO決定のためのArt of SLO』 https://sre-next.dev/2022
SLOの運用のために OSS shimesabaの導入 - KAYAC engineers' blog
カヤックSREの池田です。今回は、カヤックのプロダクトの一つ『Tonamel』で導入したエラーバジェット算出ツール shimesabaの話をします。 shimesabaとは？ github.com shimesabaは監視サービスであるMackerelを用いて、エラーバジェットを計算しサービスメトリックとして投稿することでSLI/SLOの運用を助けるツールです。 このツールを用いることで、以下のようなグラフが得られます。 この図の上部は、エラーバジェットの使用率=信頼性の損失率の推移を表すグラフになっています。 この図の下部は、エラーバジェットをいつ？どのくらい？損失したのかを表すグラフになっています。 一言で、エラーバジェットと言ってもいくつかの計算方法が存在します。 今のところshimesabaでは、Rolling windowのコンプライアンス期間で、Windows-based SL
ステージング環境における検証用データベースの立ち上げを自動化する取り組み - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。 カヤックのサービスでは、信頼性の担保を目的として、ステージング環境を作成する方針を取っています。 ステージング環境では、検証の精度を高めるために、量・質ともに本番環境に類似したデータベースが求められる局面が頻出します。 そこで今回は、Tonamel という自社サービスにおける、検証用データベースの立ち上げを自動化する取り組みについて紹介します。 サービスの置かれていた状況と解決方針 Tonamel の実行基盤は Amazon Web Services (AWS) 上にあり、本番環境とステージング環境は別のアカウントとして、同一の AWS Organizations 組織内に構築されています。 もともと、ステージング環境では、本番環境のデータは利用せず、手作業でダミーデータを作成していました。 それゆえに、データベースに格納されているデータ量は本番環境と
カヤック×PR TIMES合同 カヤック社内ISUCONを開催しました - KAYAC engineers' blog
カヤックSREの今です。 今年も4月に新卒社員を迎え、4月の後半には技術部研修を行いました。 技術部研修の締めには毎年なにかしらのイベントを行うのが恒例になっており、昨年は社内CTFを開催しました。 今年は、カヤックでは2年ぶりとなる社内ISUCONを開催しました。 新卒のみなさんはオフィスへ集まってもらいました ISUCON1とは Iikanjini Speed Up CONtestの略で、出題されたwebサービスを競技時間内にいい感じにスピードアップするコンテストです。 参加者にはWebサービスが動作する環境と初期実装のソースコード、MySQL等などのソフトウェアの初期設定ファイルが配布されます。 制限時間内でWebサービスの動作が変わらないように変更を加えて、最終的にベンチマーカーが計測するWebサービスのスコアを競います。 Webサービスの構成は問題によって変わります。アプリケーシ
「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チームでポストモーテムを1年半運用してみた - KAYAC engineers' blog
SREチームの藤原です。今回は、SREチームが主導してポストモーテムを書く取り組みを、社内で1年半ほど運用してみたという話です。 ポストモーテムとは? 「ポストモーテム」(postmortem=事後検証)とは、システムにインシデントが発生したことによる影響、緩和や解決のために取られた行動、インシデントの原因、再発防止策などをまとめた文書です。 カヤックのSREチームは、各メンバーがそれぞれのプロダクトに参加し、他のエンジニアとともに開発と運用を行う、いわゆる「Embedded SRE」という形態を取っています。そのため、SREチームのメンバーでも自分が関わっていないプロダクトで発生したインシデントについては詳しく把握できないことがありました。SRE以外で運用に携わっている、プロダクト専任のサーバーサイドエンジニアにはなおさら困難でした。 また、インシデント発生時に実際に手を動かす人がどうし
カヤックの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名体制でしたが、メンバー
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の存在 非エンジニアにもわかってもらおう 「
月間1600万PVを誇るECサイトの裏側を聞く！クラシコム×カヤック合同勉強会 - KAYAC engineers' blog
こんにちわ、こんばんわ、おはようございます、谷脇です。 今回は、北欧、暮らしの道具店を運営している株式会社クラシコムさんとカヤックで、合同勉強会を行いました。この記事では、その模様をお伝えします。 クラシコムさんの社内勉強会「ヒュッゲ」 クラシコムさんのオフィスにカヤックのメンバーがお邪魔して、勉強会を行いました。勉強会をした部屋はこのような感じです。 クラシコムさんでは月1回程度、「ヒュッゲ」と呼ばれる勉強会を開催しているそうです。「ヒュッゲ」はデンマーク語で「居心地の良さ」という意味です。名前の通り、会場は居心地よく、温かい雰囲気の中で勉強会は行われました。 クラシコムさんのレポートは 月間1600万PVのECサイトの裏側！カヤック×クラシコム合同勉強会しました になります。 それでは、各発表を簡単に振り返っていきます。 まずは自己紹介 まず、クラシコムさんの技術スタックや社員のみなさ
GitHubを利用したタスク管理ツール「ライチ」 - KAYAC engineers' blog
久しぶりのエントリーになります。技術部の永安です。今回は、社内で企画開発している内製タスク管理ツール「ライチ」の紹介をします。 「ライチ」とは GitHub上で動作する、Chrome拡張機能と組合せて使うタスク管理を行うサーバアプリです。誰でも簡単に使えるようにという理由でユーザーが触れる部分はChrome拡張としてつくられています。主に提供している機能は以下の二つになります。どちらもChrome拡張機能によってGitHubに統合されて利用することができます（後述するZenHubと同じです）。 タスクカンバン（スプリントバックログ） バーンダウンチャート タスクカンバン（スプリントバックログ） バーンダウン 「ライチ」では、GitHubのリポジトリのイシューのコメント機能を使ってタスクの管理を行います。これはイシューをスクラムでいうストーリーカードという位置付けにしているためです。大雑把な
ゲームサーバ勉強会#8に弊社社員が登壇します - KAYAC engineers' blog
こんにちは、もう少しで入社年数が二桁に入る竹田です。 新入社員の皆さんは、そろそろ落ち着いてきた頃でしょうか？ 5/12に行われるIGDA日本 ゲームサーバ勉強会 #8に弊社エンジニアの水野が登壇することになりました。 Goでゲームサーバ実装をして考えたこと 登壇者:水野 敬太 すべてがGoで実装されたゲームサーバを作り上げて、苦労したことや苦労しなかったことを話しつつ、楽しかった話をします。 Go言語でフル実装されたサーバアプリケーションの貴重な話が聞けるのではないでしょうか。 最速のサーバアプリケーションの実装方法なんかを期待してしまいますね。 techblog.kayac.com カヤックエンジニアが「ISUCON7」で4度目の快挙！優勝チームに話を聞きました！ | 面白法人カヤック かく言う私も聞いてみたい！！ 2018/05/14 19:30 追記 登壇の資料をアップいたしました
Dockerで開発環境構築を10倍楽にしたはなし - KAYAC engineers' blog
Lobi事業部 サービス基盤チームの長田です。 最近プロジェクト内で使用する開発環境にDockerを利用するようになったので、その紹介をします。 Dockerにしたってどういうこと？ 公開済みのWebサービスに変更を加えて動作確認をする場合、本番環境でそれを行うわけにはいきません。 ほとんどの場合はローカルマシンでWebサービスの全体または一部のコピーを動かして動作確認を行うことでしょう。 その後ステージング環境などの他の開発メンバーも触ることができる環境で動作確認やQAを行い、 問題がなければ晴れて本番環境に反映、という流れが一般的かと思います。 この「ローカルマシンでWebサービスのコピーを動かす」部分にDockerを利用している、ということです。 Dockerにしてどうなった？ Before 開発環境構築に1〜2日かかっていた After 開発環境構築がランチに行っている間に終わるよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
