こんにちは。技術部プラットフォームグループのharukinです。この記事では、私たちが提供するネットショップ作成・運用のためのECプラットフォーム「カラーミーショップ」のデータベースを、Amazon RDSのブルー/グリーンデプロイを利用し、MySQLのバージョン5.7.38から8.0.35へアップグレードした経験についてご紹介します。カラーミーショップにおいてはこれが初の試みでした。Amazon RDS固有のファーストタッチレイテンシーの解除方法や、ダウンタイム時間の計測についてもお伝えします。Amazon RDSのブルー/グリーンデプロイを活用するメリットは、本番環境に準ずるステージング環境を構築し事前検証が可能であることです。ステージング環境は約1分で本番環境に昇格させることができ、昇格時に許容ダウンタイムを超えたり、レプリケーションやインスタンスの問題が生じた場合は、自動的にプロセスが中断される安全性を備えています。ref. Amazon RDS ブルー/グリーンデプロイの概要 - Amazon Relational Database Serviceアップグレード方法の検討Amazon RDSをアップグレードする際には、インプレースアップグレードとブルー/グリーンデプロイという2つの方法があります。特にブルー/グリーンデプロイは、インプレースアップグレードよりもサービスの停止時間を最小限に抑えることができるため、大きな利点があります。ブルー/グリーンの両環境を一時的に稼働させることで発生するコスト増は避けられませんが、本番環境と同じ条件での事前検証が可能であること、アップグレード手順が簡素化され、そしてサービスの停止時間が短縮される利点は、それに充分見合う価値があると考えました。さらに、私が所属する技術部プラットフォームグループ（PFG）は、各事業部の枠を超えた組織として機能しており、各チームの知見やスキルを積極的に共有し合っています。これまでの成功事例の一つとして、minneにてpochyが行った際のAmazon RDSのB/GデプロイによるMySQLアップグレードの事例と遭遇した課題の知見があったことも、カラーミーショップでも同様のアプローチを採用する上での大きな後押しとなりました。ブルー/グリーンデプロイを試すまずはじめに、検証環境でブルー/グリーンデ

技術部データ基盤チームの@tosh2230です。この記事では、astronomer-cosmosでdbtのモデル実行条件をタグで柔軟に制御する方法についてご紹介します。記事執筆時点での利用バージョンは下記のとおりです。astronomer-cosmos: 1.3.2dbt-bigquery: 1.5.4Apache Airflow: 2.6.3Cloud Composer: 2.4.6結論astronomer-cosmos Airflowのコンポーネントでdbtモデルを管理dbt実行環境の作成dbt testの自動実行Cosmos運用開始にあたっての課題 モデルごとに適切な実行頻度が異なる複数のモデルオーナーがいる解決手段 モデル実行条件の制御複数のタグをAND条件で指定するにはParsing methodを変更するCI/CDでのmanifest.jsonの生成まとめ結論astronomer-cosmosでdbtモデルの実行条件を柔軟に制御するのにタグを使いましたDbtTaskGroupをモデルオーナーや実行周期ごとに作っていますRenderConfig.selectでタグをAND条件で指定するためにはparsing methodの設定変更が必要ですastronomer-cosmosastronomer-cosmos(以下、Cosmos)は、transformツールであるdbtをApache Airflow(以下、Airflow)で使いやすくするためのPythonパッケージです。AirflowのマネージドサービスAstroを運営している、Astronomerが開発しています。ライセンスはApache-2.0 licenseです。詳細な機能はドキュメントを参照いただくとして、ここではcosmosの代表的な機能をいくつかご紹介します。Airflowのコンポーネントでdbtモデルを管理dbt実行環境の作成testの自動実行Airflowのコンポーネントでdbtモデルを管理Cosmosはdbtモデルの依存関係をパースしてAirflow DAGへ変換します。これにより、DAGやtask, task groupといったAirflowのコンポーネントでdbtモデルを表現できます。dbtモデルを変換するには、DbtDagクラスもしくはDbtTaskGroupクラスを使います。両クラ

こんにちは。技術部プラットフォームグループのそめやポチです。春になるとゴマフアザラシ誕生のニュースが増えるので幸せを感じます。この記事では、Terraformと他のツールとの間で情報を共有するために、設定値をyamlファイルに切り出して管理する方法を紹介します。概要Terraformは、インフラストラクチャの構成をコードとして管理するツールです。Terraformにおいては、開発者はインフラリソースをコードによって宣言的に記述できます。記述されたリソースは他のTerraformコードから参照可能です。しかし、Terraformが管理する値をTerraformの外部、例えばCI/CDワークフローなどの他のツールから直接的に参照することはできません。そこで、Terraformと他のツールとの間で設定値を共有するために、構造化データファイルを使用することにしました。Terraformにはjsondecodeやyamldecodeといった関数があります。これらの関数によって、jsonやyamlなどの形式で書かれたデータをTerraformファイル内で解釈できます。また、jsonやyamlは広く使われている形式であるため、他のツールとの組み合わせが容易です。したがって、共有が必要なデータを構造化データファイルに書き出すことによって、Terraformと他のツールとの間でデータを共有することができます。この記事ではyamlファイルを使用した例を紹介します。コード例Terraformがyamlファイルの内容を読み取るには、yamldecode関数とfile関数を使用します。以下の例では、variables.yamlファイルに記述された値を読み取り、localsブロック内で変数として使用しています。# variables.yamlip_addresses: - 1.1.1.1 - 2.2.2.2# main.tflocals { ip_addresses = yamldecode(file("variables.yaml")).ip_addresses}output "ip_addresses" { value = local.ip_addresses}このoutputの結果は次のとおりになります。Changes to Outputs: + ip_addresses = [ + "

こんにちは。SUZURI事業部の@kromiiiと申します。私のメインの業務はWebアプリケーションの開発ですが、大学院時代のスキルを活かして並行してデータ分析業務も行っています。データ分析業務ではデータベースのクエリを書くことが多いのですが、私自身SUZURI事業部に配属されたばかりで、テーブルの名前やリレーションを覚えるのが大変でした。そこでクエリの設計を自動化するツールをSlackに導入しました。その名も tbls-ask bot です。どのようなものか先に見てみましょう。ユーザーはSlackでメンションする形で、どのようなクエリを実行したいのか自然言語で入力します。メンションされるとSlack botが起動し、どのDBスキーマを利用するかを尋ねます。ユーザーがDBスキーマを選択すると、自然言語からSQLクエリを生成し、Slackに返答します。今回はパブリックに公開する記事のため、サンプルとしてWordPressのスキーマを利用していますが、実際の社内のSlack botではそれぞれのサービスのDBスキーマが選択が可能となっています。導入背景データベースのクエリを書く際、SQLを書くことが一般的です。しかし、SQLは人間が直感的に理解しやすい言語ではありません。SQLを書く際にはデータベースのスキーマやテーブルの関係性を理解し、効率的なクエリを設計する必要があります。この作業はマーケターやディレクターなどの非エンジニア職がデータ分析を行う上で大きな障壁となっているだけでなく、エンジニアでも会社に入りたての人などドメイン知識を持たない人にとってはハードルが高い作業であると言えます。この問題を解決するため、データベースのスキーマやテーブルの関係性を自動で解析し、自然言語からSQLクエリを生成するツールが開発されています。代表的なもので言うと、Chat2DBやSQL Chatのような製品が挙げられます。しかしこうした外部のソフトウェアは商用のため導入に当たってそれなりのコストがかかります。また、多くの場合DBに対する接続権限を要するため、セキュリティ上のリスクも伴います。私が考えたアプローチ上記の問題を解決するため、私はDBのスキーマ情報からSQLクエリを生成するツール tbls-ask をSlackアプリとして開発しました。tbls-askは、tblsというDBの

minne事業部プロダクト開発チームのtepiです。先日minneのモバイルチームで「合宿」を行いましたのでその様子をご紹介したいと思います。実施内容について成果 良かった点反省点合宿の最後に打ち上げ！各パートナーの一言感想 kyuumatoshifumyyagijinまとめ実施内容についてデザインチームで合宿を行って有意義だったという話を聞きつけ、モバイルチームでもできないかと考え実施してみました。成果これまで「やりたい」で止まっていたAIを使った実装や動画の実装のプロトタイプを作成し、事業部内でデモを見せることができました。まだminneのモバイルアプリで活用できていない機能でしたが、活用のイメージが湧いてくるなど他部署の方からもポジティブな意見をもらえました。さらに、その過程で気づいてなかった改善点も発見し、改善に向けた実装を行うことができました。一方で合宿の目的である、「DAUの向上のための施策」はモバイルエンジニアのみで完結する施策がなく、実装には至りませんでした。良かった点集中した作業時間やりたいで止まっていた作業の可視化みんなで集まって作業する楽しさ反省点お題に関する諸々時間が短かった作業の分担合宿の最後に打ち上げ！このために今回のモバイル合宿をやったと言っても過言ではありませんが、なかなか一同に介することがないモバイルチームのメンバー全員でお酒を飲みました！今回の開催場所のGMO Yoursでは、毎週金曜日18:00 ~ 21:00にBar Timeが開催され、社員や招待者であればお酒・食事が無料で提供されています。さらに合宿を実施した3月29日は「GMO すごい花見 2024」と題して、桜の木を部屋の中に飾り特別メニューを提供するイベントを開催しており、お花見気分でメンバー同士親睦を深めました。各パートナーの一言感想kyu最初はDAU向上のための取り組みというお題でしたが、意見が発散してしまう場面も多く、事前準備が不足していたことには反省があります。最終的には個々人が思いついた課題やトピックについて、実際に実装を行う会となり、普段の業務と違いエンジニアが起点での取り組みを行うことができたので、非常に興味深く楽しめました。今回の取り組みからエンジニア起点での機能提案や改善も今後はできるようにエンジニア以外の方とコミュニケーションをとりアプリをより良い

こんにちは、最近は旅行しているか、コードを書いているかの２極化が進みつつあります、P山です。直近の業務において、私が支援している国内最大級のハンドメイドマーケットサービス minne において画像変換サーバの実装を変更し、大幅にコストダウンできたので、その事例を紹介します。minneについて minneはハンドメイド作家が創作したハンドメイド作品を販売することができるハンドメイド作家支援サービスです。技術スタックとしてはRuby on Railsを軸に、実行環境はOpenStackとAWSを用いたデュアルスタックのKubernetesを利用しており、スマートフォンアプリもiOS、Androidともに提供しています。 幅広い技術を、モダンな構成で扱うことができるので、もし採用にご興味があれば採用ページ をご確認ください。ペパボ社内を見渡しても若いメンバーが比較的多く、日々活気のある開発がされています。なにか個人的に相談したいことがあれば DM で質問もお待ちしております。画像変換サーバについて minneの画像配信はオリジナルのデータをS3に保存して、その前段にLambdaで実行される画像変換サーバがあり、変換した画像をCloud Frontで配信しています。ImageMagickからlibvipsへ 画像変換サーバについては、Go言語を用いて実装されており、変更前の画像変換についてはImageMagickを利用して実行されていました。今回、ImageMagickからlibvipsのGo言語のバインディング実装であるh2non/bimgを利用した実行に変更しました。なお、ImageMagickが利用されていた経緯としては、Go言語のimageパッケージを利用したところ、我々の環境ではうまくカラープロファイルが引き継がれないという問題があったため、ImageMagickをexecして利用するような実装になっていました。 下記にImageMagickとlibvipsのjpgイメージを用いたベンチマークの結果を示します。# サイズ変換処理BenchmarkConvertImageUseImageMagick-11 22 56439328 ns/opBenchmarkConvertImageUseLibVips-11 129 9790194 ns/op# サイズ変換+jpgか