こんにちは、AIShift バックエンドエンジニアの石井(@sugar235711)です。 AIShiftでは去年の11月からAI Worker[1]という新しいサービスの開発が始まりました。(以下AI Worker) 本格的に開発が始まり3ヶ月弱経ったので、その間に試してきた技術やチームの取り組みについてまとめてみたいと思います。 はじめに この記事では、AI Workerのおおまかな概要・設計を説明し、それらのバックエンドを実現する上でどのような技術を試してきたのか、技術以外でのチームの取り組みについてまとめます。 少し分量が多いので、ライブラリについての情報を求めている方は、目次から気になる部分を読んでいただければと思います。 何を作っているのか ざっくりまとめると、Microsoft Teams/Web上で動くAIを活用した業務改善プラットフォームを作成しています。 GPTとRAG
(勤務先に投稿した社内ブログの焼き直しです) ある日同僚から ActiveJob の perform_later で Barbeque にキューした非同期ジョブの起動が遅いと言われた。が、非同期ジョブの使い所について個人的な考えを書いてみることにする。 相談は「非同期ジョブの結果をユーザーに返しているため、高速になって欲しい。現状、最大で数分の時間を要す旨のメッセージを表示している」という内容でした。具体的には {内部 API} が重く、一部の処理を非同期ジョブにしていてユーザー体験の悪化につながっているとのこと。 盲目的に非同期にしても嬉しいことはない 結論としては、非同期にするのであれば丁寧にやれば良いけど、そもそも同期的でよくない? と考えて欲しいと返した。 まず、個人的にはユーザーアクション起因かつユーザーへフィードバックする必要のある処理を非同期ジョブにするのは本当に長時間かかる
PHPerKaigi 2024の登壇資料のほうが図面がわかりやすいので記載する。 ※2024/06/25 追記 speakerdeck.com どうもキャッシュバスターズ、 id:Soudai です。 Cache(以下、キャッシュ)は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒め
この記事は、株式会社カオナビ Advent Calendar 2023の2日目です。 カオナビでは2022年9月からArchitectural Decision Record(以下ADR)を導入開始しました。本記事ではADRを導入し実際に一年間運用して見た経過をご報告しつつ、導入のポイントや注意点について紹介します。 ADRをなぜ導入したのか? まずADRについて簡単に説明すると、「アーキテクチャー設計の記録をドキュメントとして残すこと」 です。Michael Nygardのブログ記事が初出のようです。 ソフトウェア開発を行っていく間には、途中で様々な設計決定をする必要があります。例えばウェブアプリケーションであれば、データベースはMySQLにしようとか、キャッシュはRedisを使おうとかという実行環境の決定の話から、実際のプログラムの基本構造といったところまで様々です。 この設計決定は、
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
This is a guest post by Ankit Sirmorya. Ankit is working as a Machine Learning Lead/Sr. Machine Learning Engineer at Amazon and has led several machine-learning initiatives across the Amazon ecosystem. Ankit has been working on applying machine learning to solve ambiguous business problems and improve customer experience. For instance, he created a platform for experimenting with different hypothe
アプリケーションエンジニアのid:tkzwtksです。今回はバッチ処理の冪等性(べきとうせい、idempotence)について、どう考えるか/考えてきたかをご紹介します。 このエントリを書くきっかけとなったのは、はてなエンジニア有志で定期的に開催しているCloudNative推進会です。ここでは、社内のシステムをクラウドネイティブにしていくため「クラウドネイティブなシステムとはどういうものか?」を考えており、この会での「クラウドネイティブなバッチ処理」の議論も踏まえつつ説明していきます。 バッチ処理における冪等性とは メッセージ送信の信頼性を考慮する クラウドネイティブで可用性を高めるために どのような場合に冪等性を考慮すべきか 冪等な実装における3つのケーススタディ ケース1: n分前までに更新されたレコードを集計する ケース2: DB上の対象レコードを更新する ケース3: 対象ユーザー
ドメインに、データの現在の状態だけを格納する代わりに、追加専用ストアを使用して、そのデータに対して実行された一連のすべてのアクションを記録します。 ストアは、レコードのシステムとして機能し、ドメイン オブジェクトを具体化するために使用できます。 これにより、データ モデルとビジネス ドメインの同期の必要性を避けることで、パフォーマンス、スケーラビリティ、および応答性を向上させながら、複合ドメインでのタスクを簡略化できます。 さらに、トランザクション データの整合性を提供し、補正アクションを有効にできる完全な監査証跡と履歴を保持することもできます。 コンテキストと問題 ほとんどのアプリケーションはデータを操作します。またアプリケーションの一般的なアプローチは、ユーザーがデータを操作したら、データを更新して、データの最新の状態を維持することです。 たとえば、従来の作成、読み取り、更新、および削
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 CQRS はコマンド クエリ責務分離を表し、データ ストアの読み取りと更新の操作を分離するパターンです。 アプリケーション内に CQRS を実装すると、そのパフォーマンス、スケーラビリティ、セキュリティが最大化される場合があります。 CQRS への移行によって生まれる柔軟性により、システムは時間の経過と共にさらに進化し、更新コマンドでドメイン レベルのマージ競合が発生することを防ぐことができます。 コンテキストと問題 従来のアーキテクチャでは、データベースの更新とクエリに同じデータ モデルが使用されます。 このシンプルな方法は、基本的な CRUD 操作に適しています。 ただし、複雑なアプリケーションの場合、こ
When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. A good architecture is important, otherwise it becomes slower and more expensive to add new capabilities in the future. Like many in the software world, I’ve long been wary of the term “architecture” as it often suggests a
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic On designing and deploying internet-scale services James Hamilton LISA ’07 Want to know how to build cloud native applications? You’ll be hard-pushed to find a better collection of wisdom, best practices, and hard-won experience than this 2007 paper from James Hamilton. It’s amazi
DroidKaigi 2018 - Day1 Room1 16:50~ にて発表する内容です
依存がなく、テスト可能であり、クリーン。 Uncle Bobのクリーンアーキテクチャの概念を読んだので、これを私はGoで実装してみたいと思います。このアーキテクチャは、自分たちの会社である Kurio – App Berita Indonesia で使っていたものに似ていますが、少し違っています。大きな違いはなく、概念は一緒なのですが、フォルダ構造が違っています。 サンプルのプロジェクトとして、記事をCRUDで管理するリポジトリを https://github.com/bxcodec/go-clean-arch にpushしてあります。 * 免責条項 ここで使われているどのライブラリあるいはフレームワークも、利用を特別推奨しているものではありませんので、ご自身あるいはサードパーティによる同じ機能のものと入れ替えることが可能です。 基本的な考え方 ご存知のように、クリーンアーキテクチャで設計
2017/10/08 PHPカンファレンス2017
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く