ニアリアルタイムで同期される検索基盤 ~パイプライン構築編~ - コネヒト開発者ブログ
皆さん，こんにちは！MLエンジニアの柏木（@asteriam）です． 今回は前回のエントリーに続いてその後編，パイプライン構築の話になります． tech.connehito.com はじめに 再掲になりますが，我々は以下の構成で今回の検索基盤を構築しています． 検索エンジン：Amazon OpenSearch Service データベース：Amazon Aurora データ同期（ETL）：AWS Glue ワークフロー・パイプライン：AWS Step Functions・Lambda・EventBridge 後編は，検索エンジンに定期的に安定してデータを同期するために構築しているワークフロー・パイプラインに関する内容になります（下図の全量データ同期パイプラインの部分）． 検索基盤全体のアーキテクチャー概略図 もう少し具体的には，OpenSearchのindexの管理方法について説明した後に
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を使ってサービングシステムを構築する方法 学習済みモデルを含んだ推論コンテナの設定（モデルの作成） エンドポイントの構成を設定 エンドポイントの作成とデプロイ 機械
SageMaker Experimentsを使った機械学習モデルの実験管理 - コネヒト開発者ブログ
皆さん，こんにちは！機械学習エンジニアの柏木（@asteriam）です． 本エントリーはコネヒトアドベントカレンダーの15日目の記事になります． 今回は機械学習モデルの実験管理をする際に使用しているAWSのSageMaker Experimentsの活用例を紹介したいと思います． アドベントカレンダー1日目でたかぱいさんがSageMaker Processingの使い所を紹介してくれているので，こちらも併せて参考下さい． tech.connehito.com はじめに 前回のエントリー*1でML Test Scoreの話をしましたが，その際にMLOpsの大事な要素である再現性（モデル学習など）に触れました．今回はこのモデル学習の再現性のために必要な実験結果（ハイパーパラメータの引数の値，モデル評価指標など）の管理をSageMaker Experimentsでしているというお話です． ※本エ
CodeBuildを使ったECSへのコンテナデプロイ - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、CodeBuildでのECSデプロイについて書いてみました。 普段、TravisCIを使ってメインサービスのECSのデプロイを行っているのですが、新規開発するにあたりCodeBuildを使ったECSのデプロイを組んでみたのでその内容をまとめています。 内容はざっくり下記4項目について書いてます。 CodeBuildのみで行うECSへのコンテナデプロイの構成図 他のCIサービスと比べた時のCodeBuildの良さ CodeBuildの設定でハマった点 デプロイフロー CodeBuildのみで行うECSへのコンテナデプロイの構成図 CodePipelineを使ったECSへのデプロイをする選択肢もあるのですが、これだと運用フローに大きく変更が入るので今回は、現在使っているecs-deploy を使ったECSデプロイを移植する形
新米マネージャーが1on1で実践していること - コネヒト開発者ブログ
こんにちは。サーバーサイドエンジニアの @itosho です。 Bリーグ（日本のプロバスケットボールリーグ）がシーズン佳境を迎え、週末はDAZN漬けの毎日を送っています🏀*1 というわけで、今日はバスケの1on1の話…ではなくミーティングの方の1on1の話をしたいと思います。僕は半年ほど前からプレイングマネージャーのようなポジションでマネジメント業務をしており、その中で1on1ミーティングも定期的*2に実施しています。 1on1については導入企業も増えてきており、事例も広く公開されてるようになってきましたが、まだまだ現場の個別具体的なノウハウは世に出てきていないと個人的には感じています。そこでこの記事では半年間の振り返りと知見の共有を兼ねて、僕が1on1で実施した取り組みを4つ紹介させていただきます。 なお、前職等でも多少のマネジメント経験はありますが、ガッツリやるのは初めて+コネヒトで
React HooksとContextAPIでFluxをやってみる - コネヒト開発者ブログ
CTO室エンジニアの安達 (@dachi_023) です。React v16.8で待ちに待ったHooksが (20日前に) リリースされました。そんなHooksを使ってFluxやる時ってどうするんだろう？と思ったので調べて写経してみました。 reactjs.org 書いたコード create-react-app して出てきたものをいじって作りました。Flux化するまでに書いたコードだけを見たい場合は コミットログ が分かりやすいかもしれません。 github.com 余談: 実際書いてみて「Hooksちゃんと理解してなかったなぁ、9割くらい写経だとしても覚えるために書くというのは良いことだ」と感じられました。 やってみる お題: +1 / -1 ができるカウンターの実装 useReducer() とContextでStoreをつくる Actionの発行 → dispatch → State
プロダクション環境ですぐに活かせそうなAWS re:Invent 2018のSageMakerアップデート5選 - コネヒト開発者ブログ
時間のない方向けにざっくり言うと 11月にSageMakerのお話で登壇したけど、12月のAWS re:Invent 2018でたくさんアップデートがあった 既存機能の強化に留まらず、「データの準備」から「モデルの変換」もサポートされるようになり、SageMakerの守備範囲がグッと広がったアップデートだと感じた この投稿はその中でもママリのプロダクションですぐに活用できそうな5つのアップデートについて内容をまとめた この記事はコネヒトアドベントカレンダーの23日目の記事です。 qiita.com こんにちは！ CTOの島田(@tatsushim)です。 先月11/1「AWS dev day」に登壇させていただきました。 そのときの資料はこちらです。 現場で用いたSageMakerについて発表させていただいたのですが、私の発表の翌月にre:Inventがあり、SageMakerも大きくアッ
DockerとJavaScriptの付き合いかた - コネヒト開発者ブログ
こんにちは。エンジニアの安達 (@dachi_023) です。会社用アカウントとして @ry0_adachi を用意していましたが全然呟かなくなっちゃったので辞めました。複数アカウントの運用って面倒ですね...。はい、コネヒト Advent Calendar 2018 の20日目はDockerとJSです。 まえがき DockerfileにJS (とかCSSとかHTMLとか) のビルド処理を書いてコンテナ立ち上げてブラウザで見えるところまでの話です。 本記事では最低限これができていればそんなに遅くならないよねってものをいくつか書いています。コードは GitHub に上がってますのでそちらを見ていただいてもOKです。このコードは create-react-app で生成したものをビルドしてコンテナ上のNginxで公開するという簡単なものですが、実際にママリのProduction環境に投入したも
AWS Fargateを本番運用した所感 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 今回は、Fargateを本番投入し1ヶ月強が過ぎたので、運用する中で気付いた点について書こうと思います。 以前書いた、Fargateに関する調査のまとめ記事はこちら。 tech.connehito.com 内容はざっくり下記3項目です。 いきなりFargateはハードルが高め 良かった点 コンテナのリソースキャパシティを簡単に変更出来る オートスケーリングもシンプルに組める 安定運用 つらい点 タスクの起動速度がEC2バックエンドと比べるとやはり遅い 料金面 いきなりFargateはハードルが高め Fargate導入を通して一番感じたのは、新規にコンテナ化するアプリケーションをECSで動かす場合、EC2バックエンドで試験をパス出来る状態まで持っていった後に、最後にFargateで動かすパターンがよさそうということです。 今回のF
チームに「効く」ダッシュボードを考える - コネヒト開発者ブログ
Creating Effective Dashboards こんにちは、サーバーサイドのお仕事してます金城(@o0h_)です。 つい先日、なんか気分が乗らないぜ〜〜って時にスピナーベイトを読み直してみたんですけど、気分の悪さが・・・上塗りされました・・・気をつけましょう。 スピナーベイト (1) (バーズコミックス) さて、今回は抽象的な話になります。 「チームで毎日見るようなプロダクトの成長のためのダッシュボードってどういうのを作るんだっけ」という内容です。 TL;DR 以下のポイントを抑えると「効くダッシュボード」ができるのでは、と考えています。 「なんとなく」で作るのはダメ🙅 目的を持ち、「誰が」「いつ」「何のために」という意図を明確にする 通常のプロダクトと同じく「UX」「ペルソナ」大事 「必要なこと」を厳選する。全てをダッシュボード上でやる必要はない digるのは他の場所で。ダ
gdpというGo製のCLIツールを公開しました - コネヒト開発者ブログ
おはようございます。こんにちは。こんばんは。 高校野球が大好きなリードエンジニアの @itosho です。甲子園が終わってしまったので、夏も終わりです。 実は先日ひっそりとGoで書いたCLIツールをOSSとして公開したので、今回はその宣伝をさせていただきます。リポジトリはこちら！ github.com 何が出来るのか？ 一言で言うと「tagの作成とリリースノートの作成」が出来ます。はい、それだけです。 tagの作成 tagの作成と言ってしまえばそれだけなのですが、弊社のサーバーサイドのリポジトリはGitHubのmasterブランチにマージされたタイミングでステージング環境にデプロイされる運用になっています。 また、tagがpushされたタイミングで本番環境にデプロイされるようになっており、tag pushがデプロイ戦略において重要な役割を担っています。 もちろん、tagを追加してpushす
Amazon Auroraの良さについてまとめてみた - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 サービスで使っているDBをRDS for MySQLからAuroraへ移行するプロジェクトを進めていて、 色々と知見が溜まってきたので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。 アーキテクチャ リーダエンドポイントによる負荷分散と共有ストレージモデルのメリットが大きい リードレプリカアクセスにLB機能がある リーダエンドポイントによって、ヘルスチェック&ラウンドロビンで読み取りアクセスに負荷分散 レプリカ0の場合は、writerにアクセスがいく アプリケーション側のエンドポイントとしては、リーダエンドポイントを指すことでr53では出来なかったヘルスチェック機能付き負荷分散可能(パブリックアクセス許可しないとr53からのヘルスチェックは使えない。。) & HA Proxyやライブラリで行
Amazon ECS ScheduledTaskで実現するスマートなDockerベースのバッチ実行環境 - コネヒト開発者ブログ
こんにちは。インフラエンジニアの永井(shnagai)です。 コネヒトでは、開発環境に続き、続々と本番サービスにもDockerを導入しています。 今回は、中々運用が大変なcronでスケジュール管理するような定期的なバッチ処理を、Amazon ECSのScheduledTaskを使ってDocker駆動な環境で構築した話です。 他の方法との比較やどのように実現しているのかについて紹介したいと思います。 今回対象とするバッチの種類 今回対象とするバッチ処理は、俗に言うスケジュール系のバッチ処理で、毎日00時00分や10分毎にサイクル起動等、事前に定義した時間に正確に動くことが期待されているものです。 ※ジョブキュー形式のバッチだと、AWS BatchやEBのWorkerもしくは、SQS + Cron on EC2で処理するほうがスマートかと思います。 実行方式の選定 上記要件のバッチを実現する基
チームでのAPI開発の強い味方!!REST APIクライアント「Paw」と「Insomnia」を比較してみた - コネヒト開発者ブログ
こんにちは！今年もコナン映画にいってきました、コナンでは服部派のエンジニア結城(@super_manner)です(*´ڡ`●) さて、今回はAPIをチームで開発するうえでつよーい味方になるツールを２つ使い比べた結果をご紹介しようと思います!! そもそもPawとInsomniaとは？ 双方ともREST APIクライアントです。 Paw paw.cloud Insomnia insomnia.rest APIを作成していると、POSTする必要があったり、User-AgentやRequestHeaderによる制約を受けたりで プラグイン追加が加速したりしますよね。 うっかりそのまま他のサイトを閲覧して全部がxmlで表示されたりすることもしばしば。 そんな煩わしさも、これらのクライアントを使うことで開放されるのです!! APIをメインに開発されている方にはもはや必需品になっているかもしれませんね。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
