「ベクトル検索 vs 全文検索」〜Amazon Bedrockの埋め込みモデルを用いたプロトタイピング〜 - コネヒト開発者ブログ
※ この記事は、AWS (Amazon Web Services) の技術支援を受けて執筆しています。 はじめに この記事はコネヒトアドベントカレンダー 8日目の記事です。 コネヒト Advent Calendar 2023って？ コネヒトのエンジニアやデザイナーやPdMがお送りするアドベント カレンダーです。 コネヒトは「家族像」というテーマを取りまく様々な課題の解決を 目指す会社で、 ママの一歩を支えるアプリ「ママリ」などを 運営しています。 adventar.org こんにちは！コネヒトの機械学習エンジニア y.ikenoueです。 突然ですがみなさん、Amazon Bedrockをご存知でしょうか。 aws.amazon.com Amazon Bedrock(以下、Bedrock)は、テキスト生成AIをはじめとする基盤モデル (Foundation Model)*1を提供するAWS
バウンスメールと AWS SES - コネヒト開発者ブログ
こんにちは！ フロントエンドエンジニアのもりやです。 先日エンジニアチーム内で AWS SES のバウンスレートについて話題になったのですが、その時に「バウンスって何？」という声がちらほら聞こえてきました。 Webサービスではユーザー登録や問い合わせなどメールが必要になる場面が多いです。 バウンスなどはメールを安定して送信するために必要な知識なのですが、なかなか担当する人以外は知られていないのかな、と思いました。 そこで今回は、バウンスメールなどのメール運用で知っておきたいエンジニア向けの知識を紹介しようと思います。 （執筆時に調べた資料などは最後に記載しておりますので、より詳しく知りたい方はそちらもあわせて読んでみてください） また、コネヒトでも使用している AWS SES の場合、バウンスをどう扱っていく必要があるかについても紹介します。 （※なお SMTP などのメールの仕組みや仕様
本番環境のAmazon Aurora MySQL v1(MySQL 5.6 互換)EOL対応でAmazon RDS Blue/Green Deploymentsを使ってアップグレードしてみた手順と所感 - コネヒト開発者ブログ
こんにちは。コネヒトのプラットフォームグループでインフラエンジニアをしている@sasashuuuです。 本日は、今年2月に対応した弊社の主力サービスであるmamariをはじめとする各種アプリケーションで使用している本番環境Amazon Aurora MySQL v1(MySQL 5.6 互換)のEOL対応において、まだリリースされてから間もない新機能であるAmazon RDS Blue/Green Deploymentsを本番導入した際の流れや所感についてまとめたいと思います。 はじめに 本記事の内容は実際にEOL対応に向けての検証を行っていた際や、EOL当日対応時の状況などを含んでおり、取り扱っているAWSサービスの仕様やその他記載内容は当時のものとなっています。最新の情報などはAWSの公式ドキュメントを参照してください。（公式ドキュメント先リンクは次項「Amazon RDS Blue/
カーディナリティが低いINDEXのお掃除をしました - コネヒト開発者ブログ
こんにちは！サーバーサイドエンジニアをやっている @otukutun です。 最近slow query起因のレイテンシアラートが発生していてRDB(MySQL)が不安定になってしまう事象が発生し、それはカーディナリティが低いINDEXが使われたことが原因で発生していました。今回は、その対応としてカーディナリティが低いINDEXのお掃除を行ったのでそれについて書きたいと思います。 なぜカーディナリティが低いINDEXを削除したのか? 一般的にカーディナリティが低いINDEXの弊害などはいろんな方が言われていますが、 効果が低いのでSELECTの性能向上にはつながらない INSERT時にINDEXの更新がされるのでINDEX数が多いほどINSERTが遅くなる(USE THE INDEX, LUKE「インデックスを作れば作るほど、INSERTが遅くなる」より引用) などがあると思っております。詳
AWS SESでハードバウンスのようなメールがソフトバウンス扱いで届いた場合のしくみと対処について - コネヒト開発者ブログ
こんにちは、インフラエンジニアのささしゅう（@sasashuuu）です。 本日はAWS SESにおけるバウンスメール周りのお話をしようと思います。 タイトルにもあるように、ハードバウンスのようなメールがソフトバウンス扱いで届き、気になってサポートへ問い合わせた際のお話をご紹介します。 バウンスメールとは そもそもバウンスメールとはなんらかの原因により配信できなかったメールのことで、その種類にはソフトバウンスとハードバウンスがあります。 違いは以下のような内容です。 ソフトバウンス 一時的な原因による配信失敗のメール（送信先のメールボックスがいっぱいだったなど） ハードバウンス 恒久的な原因による配信失敗のメール（そもそも宛先のメールアドレスが存在しないなど） 詳細な内容は過去のブログでも取り上げておりますので、よろしければご覧ください。 tech.connehito.com 届いたメールの
AWS Step FunctionsのRestoreDBClusterFromSnapshotだけではクラスタに紐づくインスタンスは作成されない - コネヒト開発者ブログ
こんにちは、インフラエンジニアのささしゅう（@sasashuuu）です。 本日は、Step Functionsを用いてデータの同期更新システムを構築した際に少しだけハマったポイントについてご紹介です。 Step Functionsとは Step FunctionsとはAWSの各種サービスを組み合わせた一連の処理の自動化などがローコードで行えるAWSのサービスです。 aws.amazon.com 弊社でも過去にいくつかStep Functionsを使用した導入事例を記事にしているので、もしご興味があればご覧ください。いくつかピックアップしておきます。 tech.connehito.com tech.connehito.com tech.connehito.com やりたかったこと 前述したように、Step Functionsのワークフローを用いてデータの同期更新をするシステムを構築していまし
ECS×Fargateのオートスケールをチューニングしてサービス運営費を削減した話 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、ECS×Fargateで運用しているサービスの「ターゲット追跡ServiceAutoScalling」をチューニングをしたことで、費用が約半分になるという大きな成果を残すことが出来たのでその内容を経緯と共にまとめています。 内容はざっくり下記3点です。 なぜオートスケールのチューニングをしたのか? 「ターゲット追跡ServiceAutoScalling」のチューニング方法 どんな結果になったか? なぜオートスケールのチューニングをしたのか? コネヒトではWebのアーキテクチャはほとんどECS×Fargateの基盤で動かしています。そして、オートスケールとして「ターゲット追跡ServiceAutoScalling」を使うことで、Fargateのメリットを最大限活かす形で運用コスト低くサービス運用を実現しています。 ここらの
SageMakerとStep Functionsを用いた機械学習パイプラインで構築した検閲システム（後編） - コネヒト開発者ブログ
皆さん，こんにちは！機械学習エンジニアの柏木（@asteriam）です． 今回は前回のエントリーに続いてその後編になります． tech.connehito.com はじめに 後編は前編でも紹介した通り以下の内容になります． 後編：SageMakerのリソースを用いてモデルのデプロイ（サービングシステムの構築）をStep Functionsのフローに組み込んだ話 モデル学習後の一連の流れで，推論を行うためにモデルのデプロイやエンドポイントの作成をStep Functionsで実装した内容になります． 今回紹介するのは下図の青枠箇所の内容になります． 検閲システムのアーキテクチャー概略図 目次 はじめに Step Functionsを使ってサービングシステムを構築する方法 学習済みモデルを含んだ推論コンテナの設定（モデルの作成） エンドポイントの構成を設定 エンドポイントの作成とデプロイ 機械
コネヒトの機械学習プロジェクトにおける構想フェーズ・PoCフェーズの進め方 - コネヒト開発者ブログ
みなさんこんにちは。機械学習チームのたかぱい（@takapy0210）です。 最近はワールドトリガーというアニメにハマっておりまして、2022年から第3期の放映が始まっております。 内容はよくあるバトルアニメですが、チームで戦略を練って戦うところがユニークでとても面白いです。（個々の力だけだと到底叶わない相手に対して戦略で勝つ、という展開もあり、戦略の大事さを改めて痛感しました） さて本日は、コネヒトの機械学習プロジェクトがどのように推進され、開発・実装フェーズに移行していくのかについて、1つの事例を交えながらご紹介できればと思います。（※あくまで1つの事例なので、全てがこのように進むわけではありません） 目次 今回のプロジェクト概要 機械学習プロジェクト全体の流れ 構想フェーズ：ビジネス要件を明確にし、共通認識をつくる どんな効果を期待しているのか？（ROI的な話） PoCフェーズ：定量
AWS CodeBuild を使った検証環境へのデプロイ改善 - コネヒト開発者ブログ
こんにちは！ フロントエンドエンジニアのもりやです。 コロナの影響でコネヒトも３月からフルリモート体制が始まり、早４ヶ月が過ぎました。 流行に乗り遅れがちな私は、今になって自宅のリモートワーク環境を整えようと動き始めています。 まずはローテーブルを卒業しよう・・・。 さて、今回はそんなフルリモート下で発生した課題の１つを CodeBuild を使って解決したので紹介させていただきます。 コネヒトにおける検証環境のデプロイ方法について コネヒトでは、本番リリース前のチェックや開発時にAWS環境で動作確認に使う検証環境を用意しています。 この検証環境にデプロイするには以下の２つの方法がありました。 master ブランチにPRをマージする（本番リリース前に動作確認するため） 開発PCから直接デプロイする（開発時に検証環境で動作確認したい時など） 2. の方法をコネヒトでは「ローカルデプロイ」と
ECS Scheduled Taskの管理をecscheduleでGitOps化しました - コネヒト開発者ブログ
こんにちは。コネヒトのテクノロジー推進グループでインフラエンジニアをしている laughk です。 今回は定期実行バッチで利用しているECS Schedule Taskの管理に Songmu/ecschedule を導入し、GitOps化した話をまとめます。 サマリ ecscheduleを導入する前の定期実行バッチの管理状況と課題 技術選定 - ecshceduleを選定した理由 導入プロセス GitOps化 導入後どうなったか ecscheduleを導入する前の定期実行バッチの管理状況と課題 コネヒトでは提供するサービスのWeb基盤にAmazon ECSをフル活用しており、定期実行バッチにおいてもECS Scheduled Taskを利用しています。ECS Scheduled TaskはECS Taskを cron のように定期実行でき、とても便利なものです。一方でその管理においては利用
コネヒトでネイティブアプリをグロースさせるために使っているSaaS - コネヒト開発者ブログ
こんにちは！コネヒトでアプリケーションエンジニアをしているaboです。 今回はコネヒトで特にネイティブアプリをグロースさせるために使っているSaaSを、それぞれどう使っているかも合わせて紹介します。 今回紹介するのはこの４つで、ざっくりとした使い方は以下の通りです。 Firebase：クラッシュ分析や、A/B テストなど KARTE：ポップアップ配信 Repro：プッシュ通知配信 Mixpanel：フローやファネル、リテンションなど多様なデータ分析 それぞれについてもう少し詳しく紹介していきます。 Firebase のつかいかた Firebase は多くの機能を持つアプリ開発プラットフォームですが、コネヒトでは以下の機能をつかっています。 Firebase Analytics：BigQuery とリンクさせて多様なデータ分析 Firebase Crashlytics：クラッシュ/非重大なイ
ECS×Fargate ターゲット追跡ServiceAutoScallingを使ったスパイク対策と費用削減 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、ターゲット追跡ServiceAutoScallingを使い、ECS×fargateで運用しているサービスのスパイク対策と費用削減に取り組んだのでその内容をまとめています。 内容はざっくり下記4項目について書いています。 抱えていた課題 キャパシティプランニングに対する考え方 ECS ターゲット追跡ServiceAutoScallingとは何か? どんな結果になったか? 抱えていた課題 コネヒトでのWebのアーキテクチャはほとんどがECS×Fargateの基盤で動かしています。 ECSのバックエンドをEC2からFargateに移行したタイミングで、大きく下記2点のメリットは享受していました。 EC2を意識しないことでの運用コスト削減 オートスケールの容易さ ですが、サービス運用にあたりまだ下記のような課題がありました。 ①
コネヒトで実践しているチームビルディングのワークショップ4選 - コネヒト開発者ブログ
はじめに 本記事は コネヒト Advent Calendar 2018 の25日目のエントリーになります。遂に最終回！メリークリスマス！ こんにちは。アルバルク東京🏀を応援している @itosho です。バスケットボールと言えばチームスポーツ！と言うわけで、今日はいつもと趣向を変えてチームビルディングにフォーカスを当てたいと思います。 コネヒトでは開発手法としてスクラムを導入しているのですが、チーム一丸となって「スクラム」を組んで開発を進めていくためにはチームビルディングが不可欠です。 僕は約1年前からスクラムマスターをやらせてもらっているのですが、チームビルディングをしていくにあたって最初はとても苦労しました。*1それは、チームビルディングに「銀の弾丸」はなく組織 / 現場毎に課題や状況の変数が異なるため、教科書通りにやってみても上手くいかないケースが多いからだと考えています。*2 そ
RDS for MySQLからAuroraへの移行 〜Auroraリードレプリカを利用した低コスト移行方式〜 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、メインサービスで使っているDBを、RDS for MySQLからAmazon Auroraへ移行した話について書こうと思います。 Auroraの良さについては、一つ前のブログにまとめているので気になる方はこちらをご覧ください。 tech.connehito.com なぜAurora移行を行ったのか 可用性を担保しながら、コストメリットが享受できる RDS for MySQL時代は可用性を確保する為に、マスター、レプリカ全て MultiAZ構成で組んでいました。しかし、MultiAZだとアクティブ-スタンバイ構成なので、スタンバイ機はトラフィックを捌かず寝ている状態になります。 Auroraにすることで、マスター - レプリカ間のフェイルオーバーが可能になり、全てのRDSインスタンスをアクティブに運用することで、同じマスタ
AWS Glueを用いてETL環境を構築したお話（RDS for MySQL → S3） - コネヒト開発者ブログ
はじめに こんにちは。2019年3月にMLエンジニアとしてJOINした野澤（@takapy0210）です。 最近はThe Mentalistという海外ドラマにお熱です。犯罪コンサルタントとして活躍する主人公の歯に衣着せぬ物言いやテンポの良さなど、見ていて爽快ですし一つ一つの作品が短いので気軽に楽しめます。（心理学に興味があると楽しさ倍増です） 前置きが長くなりましたが、初めてコネヒト開発者ブログに登場です。テンポ良くいきたいと思いますので、どうぞよろしくお願いします！ 今回は機械学習基盤アップデートの一環としてAWS Glueを用いてETLしてみた話について、苦労したポイントなどを中心にお話できればと思います。 はじめに 導入背景 結論 AWS Glueとは 言葉の定義について 構築したアーキテクチャ 構築手順 構築する際のポイント Glueには自己参照ルールが必要だった件 RDS for
Amazon Auroraの良さについてまとめてみた - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 サービスで使っているDBをRDS for MySQLからAuroraへ移行するプロジェクトを進めていて、 色々と知見が溜まってきたので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。 アーキテクチャ リーダエンドポイントによる負荷分散と共有ストレージモデルのメリットが大きい リードレプリカアクセスにLB機能がある リーダエンドポイントによって、ヘルスチェック&ラウンドロビンで読み取りアクセスに負荷分散 レプリカ0の場合は、writerにアクセスがいく アプリケーション側のエンドポイントとしては、リーダエンドポイントを指すことでr53では出来なかったヘルスチェック機能付き負荷分散可能(パブリックアクセス許可しないとr53からのヘルスチェックは使えない。。) & HA Proxyやライブラリで行
Docker運用基盤をECSからFargateにリプレイスした未来について考察してみた - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 この記事はコネヒト & aws-fargate Advent Calendar 2017 22日目の記事です。 ※本当は別記事二本書く予定だったのですが、パワー不足で一本にまとめさせてもらいました。 コネヒト Advent Calendar 2017 - Qiita AWS Fargate Advent Calendar 2017 - Qiita コネヒトでは、本番環境のほとんどのサービスでDockerを導入し、ECSを使ってサービス運用しているのですが、今回のre:Inventで発表されたFargateにこの環境を置き換えるとどんな未来が待っているかについて、考察してみました。 現状の自分が認識している情報ベースで書いているので、正確な情報とはいえずツッコミあれば指摘いただけると幸いです。 目次 Docker導入で何を目指した
AWS Fargateを本番運用した所感 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、Fargateを本番投入し1ヶ月強が過ぎたので、運用する中で気付いた点について書こうと思います。 以前書いた、Fargateに関する調査のまとめ記事はこちら。 tech.connehito.com 内容はざっくり下記3項目です。 いきなりFargateはハードルが高め 良かった点 コンテナのリソースキャパシティを簡単に変更出来る オートスケーリングもシンプルに組める 安定運用 つらい点 タスクの起動速度がEC2バックエンドと比べるとやはり遅い 料金面 いきなりFargateはハードルが高め Fargate導入を通して一番感じたのは、新規にコンテナ化するアプリケーションをECSで動かす場合、EC2バックエンドで試験をパス出来る状態まで持っていった後に、最後にFargateで動かすパターンがよさそうということです。 今回のF
ECSのバックエンドをEC2からFargateに変更するにあたり知っておくとよさそうな事 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 これまでEC2バックエンドでECSを運用してきたが、Fargateを採用するにあたり、EC2バックエンド時と比べた差分についてまとめてみました。 内容は、ざっくり下記5項目について。 NW(awsvpc) タスク定義 サービス AutoScalling メトリクス/ログ Fargateをやってみたというのは出たての頃にやったので、今回は本番運用を考えるにあたり知っておいたほうがよさそうな点についてまとめてます。 tech.connehito.com NW(awsvpc) アーキテクチャ的に一番大きく変わるのは、NWの部分だと思う。 EC2上で、タスクを動かすときはデフォルトだと「bridge」が指定されるので、ホスト経由で外部と通信を行っていた。同一タスク(コンテナのリッスンポートが同じもの)を効率的にEC2上で動かすために、動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
