さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
CQRS設計パターンをモダナイズする
CQRSとは CQRS（Command Query Responsibility Segregation、コマンド・クエリ責務分離）は、ソフトウェアアーキテクチャパターンの一つで、つまりシステムのコマンド部分をクエリ部分から分離します。基本的な考え方は、データの書き込み操作（コマンド）と読み取り操作（クエリ）を異なるモデルで扱うことです。これにより、スケーラビリティ/パフォーマンス/セキュリティの観点で柔軟な設計が可能となり、クエリ要件に合わせて最適化が実現できます。 CQRSの基本構成としては、 コマンドモデル（書き込みモデル）：データの作成、更新、削除といった書き込み操作を担当します。このモデルは、データの整合性と一貫性を確保するために最適化されています。 クエリモデル（読み取りモデル）：データの読み取り操作を担当します。このモデルは、クエリのパフォーマンスを最大化するために最適化され
AWSを使用したアプリケーションのローカルテスト
AWSを使用したアプリケーションのテスト方法 AWSを使用しているアプリケーションの開発時に問題となるのは、どのようにテストを実施するかという問題が発生します。 この時の選択肢は次の通りとなります。 単体テスト時にAWSのモックを作成してテストを行う AWS上にテスト用の環境を用意してテスト時に接続してテストを行う LocalStackを使用してローカルにAWSサービスのエミュレーターを動かしてテストする 単体テスト時にAWSのモックを作成してテストを行う 単体テスト時にモックアップする方法はテストに都合のいいデータを返せるため容易にテストが行えます。 モックの作成に手間がかかりますし、思い込みでモックを作成してバグを作成する場合もありますが、Motoなどを用いることでこれらの問題は軽減できるでしょう。 ただし、あくまで単体テストでしか使用できません。例えば複数プロセスを連携するようなテス
AWS Security Hubの導入からうまく運用を回すまでのTips / 開発者向けブログ・イベント | GMO Developers
こんにちは、GMOインターネットグループ株式会社 システム統括本部 ホスティング・クラウド開発部 アプリケーション共通チーム（技術推進チーム/AWS運用チーム）の井本です。 弊社では、AWS環境におけるセキュリティ強化の取り組みを随時実施しております。今回は、直近で実施したセキュリティ統制の取り組みである「AWS Security Hubの導入」について、ご紹介させていただきます。 はじめに みなさんは、Security HubやGuardDuty, Trusted Advisorなどを導入したものの、「各チームにご対応いただけない」、「通知が来すぎてしまう」など、うまく運用を回すことができないという状況に直面したことはないでしょうか？ 今回は、Security Hubの横断導入に際して、得られた知見をご共有させていただき、ぜひみなさんが導入・運用改善される際の参考にしていただければと思い
新規プロダクト開発にサーバレスアーキテクチャを採用 Works Human IntelligenceはERP市場 人事・給与業務分野 シェアNo.1[1]を獲得しているエンタープライズ向け統合人事システム「COMPANY」の開発、販売、サポートを行っている企業である。Works Human Intelligenceによると、COMPANYは国内大手法人の3社に1社にあたる約1200社が導入しており、約510万人の人事データを管理している。同社ではこの膨大な人事データを活用し、より顧客にとって価値のある製品や機能の開発に取り組んでいる。その一つが齋藤氏の紹介する「COMPANY Human Capital Insight（HCI）」である。HCIはCOMPANYやその他外部のシステムと連携し、人事データなどのあらゆるデータを集約。そのデータを元に男女間賃金差異や女性管理職比率などの人的資本に
CDK の中で DB を初期化する点についても後ほど触れます。 S3 にサンプルデータをアップロードする 続いて、以下のコマンドで S3 にサンプルのデータを入れます。 bucket_name=$(aws cloudformation describe-stacks --stack-name BlogAthenaJoinS3AndMysqlStack --output text --query 'Stacks[0].Outputs[?OutputKey==`BucketName`].OutputValue') aws s3 cp ./s3_test_data/data "s3://${bucket_name}/data" --recursive これで CloudFormation で作成した S3 バケット名を取得し、そのバケットに以下の CSV ファイルをアップロードしました。 ※4都
Amazon MemoryDB for Redisの論文がSIGMOD 2024で採択されたので読んでみた | DevelopersIO
Amazon MemoryDBではトランザクションログサービスへの耐久性のオフロード、スナップショット用にephemeralクラスタを作成、形式手法(TLA+)で一貫性の検証などが活躍しています Amazon MemoryDB for RedisはAWSが2021年から提供するRedis互換でありながら高速なパフォーマンスと耐久性を兼ね備えたエンタープライズなインメモリデータベースです。このAmazon MemoryDBの仕組みについて説明した論文が、2024年6月にチリ・サンティアゴで開催される国際的なデータベース学会の「SIGMOD/PODS 2024」で採択されました。 The 2024 ACM SIGMOD/PODS Conference: Santiago, Chile - Welcome Amazon MemoryDB: A fast and durable memory-fi
ドメインイベントを伝達するためのモデリング技法 - KAKEHASHI Tech Blog
前回は、アーキテクチャの進化はドメインイベントが起点になるという記事内で、ドメインイベントの重要性を語りました。本稿では、ドメインイベントを伝達する際にシステム要件を満たした上で、どのようにしてデータモデル並びにドメインモデルを象るかを説明します。 なお、ビジネスドメインを深掘りドメインモデルを探索する手法の説明は、世にたくさん解説されているため詳しくはそちらに譲ります。特にAlberto Brandolini氏が提唱するモデリング手法であるEvent Stormingは、ワークショップ形式でドメインイベントを深く理解し、一連の業務プロセスやドメイン領域を探索的に発見することができる手法であり、Event Sourcingを前提とするアーキテクチャと相性がいいので参考にするとよいでしょう。 ドメインイベントのデータモデルの属性 ドメインイベントの記録および伝達に着眼した構成を紹介した前回の
[アップデート] Amazon DynamoDB のオンデマンドキャパシティモードで最大スループットを指定出来るようになったので、YCSB で DynamoDB の負荷テストしてみた | DevelopersIO
[アップデート] Amazon DynamoDB のオンデマンドキャパシティモードで最大スループットを指定出来るようになったので、YCSB で DynamoDB の負荷テストしてみた いわさです。 DynamoDB にはキャパシティモードの概念がありまして、あらかじめ予測したキャパシティを事前割り当てしておくプロビジョンドモードか、実際に発生したリクエストに応じて請求してくれて良いのでうまいことやってくれやというオンデマンドモードの 2 つがあります。 どちらも一長一短あるのですが後者のオンデマンドの場合は柔軟性がある一方で、ワークロードの負荷によってはコストが予測しずらかったり、あるいは DynamoDB のイベントに応じてサービス間を連携しているような場合にオンデマンドだと外部サービスに予測できない負荷が発生することがありえます。 そんなオンデマンドキャパシティモードですが、本日のアッ
![[アップデート] Amazon DynamoDB のオンデマンドキャパシティモードで最大スループットを指定出来るようになったので、YCSB で DynamoDB の負荷テストしてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/38e9929fa6251377ccd1a0b39defb8126be9eef4/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F08%2Famazon-dynamodb.png)
Amazon Connect フローでの放棄呼と離脱箇所を、Step Functionsを利用しローコードでDynamoDBに保存してみた | DevelopersIO
Amazon Connect フローでの放棄呼と離脱箇所を、Step Functionsを利用しローコードでDynamoDBに保存してみた はじめに Amazon Connectのフローで離脱箇所や放棄呼をAmazon Kinesis Data Streams（以降、KDS）とStep Functionsを用いて取得し、Amazon DynamoDBに保存する方法をまとめました。 本記事の内容は以下のような用途に役立ちます。 IVRでの途中離脱箇所を知りたい オペレーターにつながる前に切られる放棄呼の有無を知りたい Connectは、各通話ごとに問い合わせレコード（Contact Trace Record, CTR）として通話記録を保存します。 Connectでは、KDSに問い合わせレコードを出力できます。通常は問い合わせレコードは、どのフローで切断されたか情報はありませんが、フロー内で工
Why reading whitepapers takes your career to the next level (and how to do it)
Hi everyone 👋, Jordan here. I’m excited to feature , L6 Staff Engineer and Tech Lead at Google, and author of , a blog with recurring deep dives on technical topics. Micah attributes a large part of his growth to reading technical whitepapers. In today’s guest post, he will share the value he’s experienced and how you can see similar results. Hi everyone 👋, Micah here. As a tech lead at Google,
当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の50日目のエントリです。 このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。 では、さっそくいってみましょう。今回のテーマはワークフローを制御する『AWS Step Functions』です。 AWS Step Functionsの概要 AWS Step Functio
AWS Support - Troubleshooting in the cloud Workshopをやってみた③
AWS Support - Troubleshooting in the cloudとは AWSが提供するWorkshopの一つで、現在(2024/5)は英語版が提供されています。(フィードバックが多ければ日本語化も対応したいとのこと) クラウドへの移行が進む中でアプリケーションの複雑性も増しています。このワークショップでは様々なワークロードに対応できるトラブルシューティングを学ぶことが出来ます。AWSだけでなく一般的なトラブルシューティングにも繋がる知識が得られるため、非常にためになるWorkshopかと思います。また、セクションごとに分かれているので、興味のある分野だけ実施するということも可能です。 学習できるコンテンツ・コンセプトとしては、CI/CD、IaC、Serverless、コンテナ、Network、Database等のシステムに関わる全てのレイヤが網羅されているので、ぜひ一度
Amazon Connect フローでの離脱箇所と放棄呼をStep FunctionsとLambdaを組み合わせてDynamoDBに保存してみた | DevelopersIO
Amazon Connect フローでの離脱箇所と放棄呼をStep FunctionsとLambdaを組み合わせてDynamoDBに保存してみた はじめに Amazon Connectのフローで離脱箇所や放棄呼をAmazon Kinesis Data Streams（以降、KDS）とAWS Step Functions、AWS Lambdaを用いて取得し、Amazon DynamoDBに保存する方法をまとめました。 本記事の内容は以下のような用途に役立ちます。 IVRでの途中離脱箇所を知りたい オペレーターにつながる前に切られる放棄呼の有無を知りたい Connectは、各通話ごとに問い合わせレコード（Contact Trace Record, CTR）として通話記録を保存します。 Connectでは、KDSに問い合わせレコードを出力できます。通常は問い合わせレコードは、どのフローで切断され
[登壇レポート]「生成AI時代の必須スキル！RAGの回答精度向上のコツ全部教えます」で登壇しました | DevelopersIO
新規事業部 生成AIチームの山本です。 2024/04/24にオンラインで開催した弊社セミナー「生成AI時代の必須スキル！RAGの回答精度向上のコツ全部教えます」にて登壇をしましたので、自分の発表資料を共有いたします。 資料 資料に関する補足 今回は、RAGを始めたい方や始めてすぐな方に向けて登壇を行いました メインの内容は、1～73ページです。 また補足として、既にRAGを導入し進めている方向けに、補足情報を74ページ以降に記載しました。 Q&A 以下、いただいた質問と、差し上げた回答の内容です。山本がメインで回答していますが、一部は（同じく登壇した）熊谷が回答しました。一部、本記事の記載に伴い補足を追加しました。 Q: LLMとragを活用し、毎日の1000人規模全社のeメール（参考ドキュメント）から、トラブルや不正予兆のあるメールを抽出することはできますか。なお、教師データ（メール）
![[登壇レポート]「生成AI時代の必須スキル！RAGの回答精度向上のコツ全部教えます」で登壇しました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/30781ec4e024829f38d7883d643b9d8e53ec927c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2024%2F03%2F240424_ai_rag_w1200h630-1.png)
【執筆者紹介】 「 西根幸洋さん」 ポジション：メタバース事業本部エンジニア部マネージャー 入社時期：2023 年 10 月 業界歴：Web サービスやオンラインゲームの開発・運営に 11 年従事。主にサーバーサイド C# エンジニアとして活動し、個人として Microsoft MVP for Developer Technologies（2020-2022）を受賞。 はじめに こんにちは、メタバース事業本部エンジニア部マネージャーの西根です。 ホロアースの開発の話といえば、Unity を使ったクライアント側の実装や、アバターやライブ演出などの話が注目されがちですが、今回はサーバーサイドで利用している技術の一部をご紹介させていただこうと思います。 ホロアースの開発の裏側を知りたい、開発に参加してみたいと思っている方の参考になれば幸いです。 開発に参加してみたいと思った方はこちらから是非ご応
Python アプリのモニタリングを Amazon CloudWatch Application Signals (プレビュー) で実施 | Amazon Web Services
Amazon Web Services ブログ Python アプリのモニタリングを Amazon CloudWatch Application Signals (プレビュー) で実施 AWS は re:Invent 2023 で Amazon CloudWatch Application Signals を発表しました。これは Java アプリケーションの健全性をモニタリングして理解するための新機能です。本日、Application Signals が Python アプリケーション のサポートを開始したことをお知らせします。 Application Signals を有効化することで、コード変更なしで Python アプリケーションに AWS Distro for OpenTelemetry (ADOT) を導入できるようになります。これにより、Python を使って開発されたライブラ
NTT東日本の中村です。 Amplify Gen2がGAとなり、プレビューで紹介されていたチュートリアルも大きく変わりました。 改めて、正式公開されたチュートリアルを確認してみました。 プレビュー版はこちらの過去の記事でまとめられていますが、GAになり、多少コマンドの変更等がありますので、ご注意下さい。 amplify → ampxにコマンドが変更 sandboxのオプションがnameからidentifierに変更 チュートリアルを始める前に チュートリアルはReact、Vue、Flutter等、言語フレームワークにより分かれていますが、今回はNextJSのApp Routerをベースに確認します。 今回はQuickStartを進めていきます。 Amplify Gen2のチュートリアル（Quick Start） 以前は無かった、QuickStartのチュートリアルで、GitHubにGen2
This article explains what event sourcing is, common use cases, considerations and examples. This document discusses an approach to building event sourced systems. The use cases, architecture patterns and implementation details using both AWS native services and open source options. Event Sourcing is an architecture pattern that stores an application’s state as an append-only log of events. As wel
定期的にDynamoDBのデータをS3バケットにCSV形式で保存するLambdaを作成してみた | DevelopersIO
はじめに Amazon DynamoDBのデータを毎日Amazon S3バケットへCSV形式で保存するAWS Lambdaを作成する機会がありましたので、紹介します。 構成としては以下のとおりです。 Amazon EventBridge Schedulerで毎日01:00にLambdaを呼出します Lambdaは、DynamoDBから前日に保存されたデータを取得します。 LambdaでCSV形式に変換し、S3バケットに保存します。 DynamoDBのテーブルは、属性としてデータを保存した日付が入っていれば、テーブルは何でもよいですが、今回は以下の記事で作成したテーブルを利用します。 本記事で使用するDynamoDBのテーブルには、start_date(保存した日付)の属性が必要です。存在しない場合は、新たに追加してください。 保存した日付:start_date（必須） 例：2024-04-
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS CDKでサーバレスのローカル開発環境を構築した理由とは？ デメリットの解消方法と実運用で直面した課題
Athena で S3 と MySQL を JOIN する | DevelopersIO
AWS入門ブログリレー2024 〜AWS Step Functions編〜 | DevelopersIO
ホロアースのサーバーサイドの技術について | Blog｜ホロアース
Amplify Gen2のQuickStartチュートリアルを進めてみた | DevelopersIO
Event Sourcing | Event-driven Architecture on AWS