こんにちは。SRE の近藤（@chaspy）です。 先日、より高い信頼性でサービスを提供するために、スタディサプリ小中高大のサービスの最後の砦であるデータベース、MongoDB のインスタンスクラスのスケールアップを行いました。また、スケールアップをするにあたり、負荷試験を行いました。 本記事では、データベースインスタンスのスケールアップの際に行なった負荷試験に対する考え方と、得た学びを紹介します。 なぜスケールアップするのか サービスの急成長に伴い、アクセス数もデータ量も増加しています。数年前に「しばらくは大丈夫」と判断できるインスタンスクラスにスケールアップをしたデータベースも、高負荷時には性能が劣化してしまう問題に遭遇しました。 私たちの MongoDB は AWS 上に EC2 インスタンスとしてセルフホストしており、MongoDB Cloud Manager を使って運用の一部を
builderscon tokyo 2019で話したときに使った資料です。 YouTube: https://www.youtube.com/watch?v=D7GccAn6R94 [2020/04/17追記] この資料をさらにブラッシュアップした資料を公開しました。 この資料よりも次の資料…
#gotanda.rb 第37回目 で発表したスライドです。
AWS Device Farm で Appium Node.js と Appium Ruby のサポートを開始
Ruby または Node.js で書かれた Appium テストが AWS Device Farm のネイティブでハイブリッドなブラウザベースのアプリケーションで実行できるようになりました。 Device Farm は、Mocha や RSpec などの JavaScript フレームワークや Ruby フレームワークに書き込まれたテストをサポートします。また、ユーザーのプロジェクトのニーズに依存性と、テスト実行中実行すべきコマンドを指定でき、テストがローカルの環境で実行されるときとちょうど同じようにしてテストできるようになりました。 AWS Device Farm は、実際のデバイスで自動テストを実行することや、Android、iOS、ウェブアプリケーションと通信することを可能にするアプリケーションテストサービスです。Device Farm は、Espresso、XCTest、Appi
Today, we’re excited to release Diffy, an open-source tool that automatically catches bugs in Apache Thrift and HTTP-based services. It needs minimal setup and is able to catch bugs without requiring developers to write many tests. Service-oriented architectures like our platform see a large number of services evolve at a very fast pace. As new features are added with each commit, existing code is
はじめに これはRecruit Engineers Advent Calendar 2016の11日目の記事ですが遅れての投稿です。すみません。 先日、xUTPの著者のセッションに行って聞いたきたので、その内容をまとめたものです。 謝辞と注意点 この記事を書くに際し、セッションのスピーカーであるGerard Meszarosさんに、特別にスライド内のコードの利用を認めていただきました*1。この場を借りて感謝いたします。Thank you for giving me the right to use code sample in Agile Singapore 2016 presentation, Mr. Meszaros! 上記の経緯から、以下に出てくるコードのライセンスはCopyright 2016 Gerard Meszarosです。ご注意ください。 Unit Test Craftma
Oct 23, 2016Download as pptx, pdf52 likes26,138 views テストやQA (品質保証) には説明責任が求められます。しかし、仕様書のコピペにすぎないテスト設計、自己目的化した自動化、規格に準拠しただけの開発 / 機能安全プロセス、おざなりな保証ケース、属人化したレビュー、ハードウェア主導のQA組織によるピントを外した品質保証など、説明責任とはほど遠い組織が多く見られます。そこで本講演ではQAアーキテクチャというコンセプトを紹介し、テストやQAの全体像を俯瞰し説明責任を高めるための方策を概説します。これにより、テスト自動化をベースとしたパイプライン化によるテストのリズムの高速化や、フロントローディングによる上流での品質作り込みサイクルの構築も目指すことができるようになります。
Is there still manual testing tasks which TE's do? Is there still a proportion of manual testing which takes place? ReplyDelete Hi Steve, TEs do not perform manual testing. However, manual testing is used by some teams at Google. In this situation, another responsibility of TEs is to formulate and execute a plan for automating as many manual tests as possible. _Matt Delete
Consumer-Driven Contracts Design Patternを読み漁ってみた
Microserviceのテストの話を調べていると、以下のような記事を見つけました。 Simplifying Micro-Service testing with Pacts このPactoと呼ばれるツールがConsumer Driven Contractsと呼ばれるデザインパターンを使っていると書いていたので、同デザインパターンを少し調べてみました。 関連: MartinFowler氏のブログ記事 Pactoに関するGitHub デザインパターンとしての説明 http://www.servicedesignpatterns.com/WebServiceEvolution/ConsumerDrivenContracts http://java.dzone.com/articles/application-pattern-consumer アプリの実装寄りの話はこの記事が参考になりそう 消費
https://atnd.org/events/66159 で実施したプレゼン資料
We blogged about the evolution of Yahoo Mail to React + Flux and Node.js. It is important to focus on building a strong foundation when you are building a new platform and having a robust test infrastructure is a big part of the foundation. Yahoo Mail today relies on automated testing on our Continuous Integration pipeline before we deploy changes to production. We run Cucumber and Waitr-Webdriver
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27（土）の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード（テストコードが無いコード）と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 ＜開催趣旨・目的＞ テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
