AWS Systems Manager Parameter Storeを便利に使うツール "ssmwrap" がv2になりました - KAYAC engineers' blog
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にこんな値が保存され
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運用も可能な選択
GitHub ActionsでEnvironmentsを使わずにManual approvalを実装する - KAYAC engineers' blog
SREの今です。 CircleCIやGitHub Actions等のCI/CDツールでデプロイの自動化に取り組む際に、意図しない本番反映の防止策として承認アクション(Manual approval)を挟んでおくことがあります。 GitHub Actionsでは、Environmentsを利用することでワークフローの実行前にレビューを必須化することが出来ます1。しかし、この機能をプライベートリポジトリで利用するにはリポジトリの所有者がGitHub Enterpriseを契約している必要があります2。 業務の都合上、Environmentsを利用できないリポジトリでManual approvalを利用したい機会があり、ワークフロー実行履歴を利用したManual approvalを実装したのでご紹介します。 本記事はSRE連載の12月号 + 面白法人グループ Advent Calendar 20
【解説編】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対応は完了しましたか？ 安心してください。私のプロジェクトでも一部未完遂です。(おい) ということで今回は、前回紹介したソースコードを深掘りして解説します。 私と同じように、途中でなんか面倒になって一旦塩漬けにしたら正直忘れかけてる長い道のりの途中にいる皆様
ecspresso v2とTerraform null_resourceで一発構築 - KAYAC engineers' blog
SREチームの藤原です。 この記事はTech KAYAC Advent Calendar 2022 5日目の記事です。 この記事では筆者が開発しているAmazon ECSデプロイツール ecspresso (v2)と、Terraformのnull_resourceを組み合わせて、 TerraformによるECS関連リソース作成とecspressoによるECSサービスのデプロイを一発で実行する手法について説明します。 ecspresso とは github.com ecspressoは筆者(fujiwara)が開発している、Amazon ECS用のデプロイツール(OSS)です。ECSにタスク定義とサービスをデプロイするツールはAWSが作っているものを含めて世の中に多々ありますが、ecspressoは次のような特徴を持っています。 Go 言語で書かれた OSS (MIT LICENSE) です
負荷試験とOSSツール選定の話 - KAYAC engineers' blog
この記事は 面白法人グループ Advent Calendar 2022 の15日目の記事です。 こんにちは、カヤックボンドの松本です。 今回は弊社の技術顧問をご担当いただいている、ドレッドノート株式会社の佐々木様よりご寄稿いただいた記事となります！ みなさん、はじめまして！ 主にパフォーマンスチューニングや検証用のボット開発等を行っているドレッドノート株式会社の佐々木と申します。 この度、カヤックグループの皆様より Advent Calendar 2022 に寄稿する機会を頂戴しましたので、2022年12月時点の方法を元に負荷試験とモダンなOSSツールについて書いてみたいと思います。 負荷試験の重要性 突然ですが、みなさんが関わっている案件で負荷試験を行っていますか？ サービス開始前・提供中、どちらであっても負荷のかけ方によって様々な情報を得ることができます。 現状の性能・台数・実装で、ど
秘密情報には出どころも書いてくれ！頼む！ - 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
NIPPON ITチャリティ駅伝にエンジニア5人のカヤックチームで出た話 - KAYAC engineers' blog
こんにちは！ Tech KAYAC Advent Calendar 2022 8日目を担当する荒賀(@ken39arg)です。 カヤックのアドベントカレンダーは観測する限り2012年から始まり今年は11回目であります。私も8回参加しており*1、2016年以降の6回はその年のランニング活動を必ず報告していたようです。 今年のランニング活動は3月にフルマラソンを走って自己ベストを40秒ほど更新したのですが*2、以降緩やかに燃え尽きてしまい月間走行距離も300kmから150kmくらいにぐっと減ってしまいました。同僚のメロンみたいな肩をしているボディービルダーは大会で入賞したので、中途半端な自分は少し恥ずかしく感じているところでございます。 さて、燃え尽きたのにも関わらず、それなりには走っているのには理由があり、先日カヤックのエンジニアで構成されたチームでNIPPON ITチャリティ駅伝という大会
ボディビル3位になった話 - KAYAC engineers' blog
こんにちは。長堂 @kzmsngd です。 今回はCalendar for KAYAC | Advent Calendar 2022 - Qiitaの初日の記事として、趣味のボディビルの話をします。 Flutterエンジニア兼ボディビルダーです 実はこのブログに登場するのは3度目です。毎回のようにボディビルに関することを書いています。 技術のことよりボディビルのことを語りたい人間です。 過去に書いた記事: techblog.kayac.com techblog.kayac.com 現在はちいき資本主義事業部でまちのコインを開発しているFlutterエンジニアです。 本格的に筋トレをやり始めて5年目、ボディビルコンテスト挑戦し始めて4年目です。コンテストの成績で言うとこれまでは予選も勝ち残れず結果を出せていませんでした。 「コンテストで結果出せないならそろそろ…」と、コンテスト出場は辞めよう
Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯（ステージング環境を後から立てたり！）から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a
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のマネージドサービスを組み合わせ
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を指定しています。 例
ステージング環境における検証用データベースの立ち上げを自動化する取り組み - KAYAC engineers' blog
SREチーム(新卒)の市川恭佑です。 カヤックのサービスでは、信頼性の担保を目的として、ステージング環境を作成する方針を取っています。 ステージング環境では、検証の精度を高めるために、量・質ともに本番環境に類似したデータベースが求められる局面が頻出します。 そこで今回は、Tonamel という自社サービスにおける、検証用データベースの立ち上げを自動化する取り組みについて紹介します。 サービスの置かれていた状況と解決方針 Tonamel の実行基盤は Amazon Web Services (AWS) 上にあり、本番環境とステージング環境は別のアカウントとして、同一の AWS Organizations 組織内に構築されています。 もともと、ステージング環境では、本番環境のデータは利用せず、手作業でダミーデータを作成していました。 それゆえに、データベースに格納されているデータ量は本番環境と
SREチームでポストモーテムを1年半運用してみた - KAYAC engineers' blog
SREチームの藤原です。今回は、SREチームが主導してポストモーテムを書く取り組みを、社内で1年半ほど運用してみたという話です。 ポストモーテムとは? 「ポストモーテム」(postmortem=事後検証)とは、システムにインシデントが発生したことによる影響、緩和や解決のために取られた行動、インシデントの原因、再発防止策などをまとめた文書です。 カヤックのSREチームは、各メンバーがそれぞれのプロダクトに参加し、他のエンジニアとともに開発と運用を行う、いわゆる「Embedded SRE」という形態を取っています。そのため、SREチームのメンバーでも自分が関わっていないプロダクトで発生したインシデントについては詳しく把握できないことがありました。SRE以外で運用に携わっている、プロダクト専任のサーバーサイドエンジニアにはなおさら困難でした。 また、インシデント発生時に実際に手を動かす人がどうし
既存リソースをTerraformでimportする作業を楽にする - KAYAC engineers' blog
SREチームの今です。 カヤックでは、クラウドリソースの管理にはTerraformを利用することが多いです。 クラウドリソースの構成や設定をコードで管理することで、リソースの変更内容の差分をレビューできる、意図しない設定変更を発見できるなどの利点があり、SREの目的であるサービスを安定して提供する上で重要な要素の一つです。 実際の作業として、既に運用中のサービスを新たにTerraform管理下に置く場合や、多くのリソースが既にweb consoleから作成されているものをTerraform管理下に追加する場合も多いと思います。 その際にはTerraform importをする必要があります。しかし、Terraform importは単純作業とはいえ時間と手間がかかり、優先順位を下げてついつい後回しにしてしまうことも多いのではないでしょうか。 今回は、手作業でTerraform import
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の存在 非エンジニアにもわかってもらおう 「
CloudFrontのS3 Originにはhostヘッダーを転送してはいけない - KAYAC engineers' blog
SREチームの長田です。 CloudFrontでstaticなファイルを配信しようとした時に少々ハマったのでそのメモです。 TL;DR CloudFront distributionのS3 Originは、Managed Policyの Managed-AllViewer を使うと機能しない。 何をしたのか statcなファイルを配信する要件があり、その対応としてCloudFront distributionのOriginにS3を設定しました。 CloudFrontのOrigin Access Identity(OAI)を作成し、S3 bucket policyにはこのOAIからのAPIリクエストのみを受け付けるよう設定しました。 docs.aws.amazon.com いざ配信用URLにHTTPリクエストすると以下のようなエラーになってしまいました。 <Error> <Code>Sign
LobiのCIをJenkinsからCircleCIに移行したはなし - KAYAC engineers' blog
SREチームの長田です。 Tech KAYAC Advent Calendar 2019 4日目の記事です。 今回はLobiで長らくCI実行環境として使用していたJenkinsから、CircleCIに移行したはなしです。 Jenkins時代 jenkins.io 皆様御存知のJenkinsです。 LobiではCI実行のために使用していましたが、ジョブ実行を定型化する汎用的なアプリケーションです。 GitHub上のリポジトリへのpushをトリガーに、対象branchについてCIを実行する、という使い方をしていました。 動作環境はAmazon EC2で、Jenkins本体が稼働しているmaster(x1)と、実際にCIを実行するslave(x2)の3台構成でした。 Jenkins時代もCIするという目的は達成されていたのですが、大きく分けて2つの課題がありました。 メンテナンス Jenkins
Lobiの画像変換サーバーをImageFlux+Lambda@Edgeで置き換えたはなし - KAYAC engineers' blog
SREチームの長田です。 先日Lobiの画像変換サーバーをImageFluxに移行したので、その過程を紹介します。 画像変換って？ Lobiはチャットを主軸としたコミュニティサービスです。 ユーザーはチャットメッセージに画像を添付することができます。 また、ユーザーアイコンやチャットグループの壁紙などもスマホやPCからアップロードして設定することができます。 アップロードされた画像は利用箇所に応じて適切なサイズ・フォーマットに変換する必要があります。 投稿画像のプレビューでは表示速度と通信量削減を優先して解像度低めの画像を、 拡大表示する場合はオリジナルサイズの画像を表示します。 複数サイズの画像を用意する手段として、Lobiでは内製画像変換アプリケーションであるmagcian1を運用していました。 Amazon EC2上で動作するNodeJS製のアプリケーションで、AWS CloudFr
カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC engineers' blog
入社4年目にもなってtech.kayac初登場のせいです。 ブログ書けプレッシャーにとうとう屈する時がきました。 これで夢にkyo_agoが出てうなされなくてすみます。(彼はtech.kayacの尻たたき担当でした) 先々月「ぼくらの甲子園!熱闘編」というゲームをモバゲー内にてリリースしました。 これは去年リリースした「ぼくらの甲子園!」の続編です。 モバゲーユーザの方、是非遊んでみてください。 今回はこの「ぼくらの甲子園!熱闘編」がどういうインフラ構成になってるか紹介したいと思います。 注) 題名に「カヤック流」とはつけましたが、カヤックでは多様性を善としている風潮があり、 ゲームによってインフラの構成が違うどころか、利用しているプログラミング言語すら違います。 なので全てのゲームがこのような構成になってるわけではありません。 前提 今回のインフラ構成を決めるに至って考慮した点は「ラクに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
