{"id":18430707,"url":"https://github.com/kompiro/incident-drill-timeout","last_synced_at":"2025-08-23T16:09:51.399Z","repository":{"id":66606571,"uuid":"564150030","full_name":"kompiro/incident-drill-timeout","owner":"kompiro","description":null,"archived":false,"fork":false,"pushed_at":"2022-11-15T04:11:08.000Z","size":164,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-04-14T00:50:00.440Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kompiro.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-11-10T05:00:22.000Z","updated_at":"2022-11-11T07:10:13.000Z","dependencies_parsed_at":null,"dependency_job_id":"79368f09-10b4-43e0-b345-6601993c9c7c","html_url":"https://github.com/kompiro/incident-drill-timeout","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/kompiro/incident-drill-timeout","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kompiro%2Fincident-drill-timeout","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kompiro%2Fincident-drill-timeout/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kompiro%2Fincident-drill-timeout/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kompiro%2Fincident-drill-timeout/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kompiro","download_url":"https://codeload.github.com/kompiro/incident-drill-timeout/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kompiro%2Fincident-drill-timeout/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":271755444,"owners_count":24815408,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-23T02:00:09.327Z","response_time":69,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-06T05:22:02.352Z","updated_at":"2025-08-23T16:09:51.367Z","avatar_url":"https://github.com/kompiro.png","language":"Ruby","funding_links":[],"categories":[],"sub_categories":[],"readme":"# インシデント体験(Timeout編)\n\n## これはなに？\n\n連携先のサービス、ミドルウェア等が何らかの原因でスローダウンを起こし、\nレスポンスが返ってこない状況を再現したリポジトリです。Main Service から Accident Service にリクエストを送りますが、Accident Service がレスポンスを返すまで100secかかるため、Main Serviceではリクエストをさばけなることを観測できます。\n\nまた、Main Serviceでは Accident Service の状況に巻き込まれないよう、適切にタイムアウトを設定することで、 Accident Service に連携しない機能は利用できることを体験できます。\n\n## 必要な環境\n\n### a. GitHub Codespaces\n\nこのリポジトリを clone 後、Code ボタンから Codespaces を開いてください。\n\n### b. その他の環境\n\n- VSCode\n  - VSCode Dev Containers Extension\n  - VSCode Remote SSH Extension を組み合わせる場合の注意点\n    - **AWS System Manager 等はサポートされていません**\n- Docker\n  - Docker Desktop (Windows \u0026 Mac)\n    - WSL2でのDockerは Dev Containers が未サポート\n  - Docker Community Edition (Linux)\n    - docker-compose-plugin をインストールすること\n    - Dev Containers がサポートするのは docker compose V2 のみ\n    - **python版のdocker-composeはサポートされていません**\n\n#### 立ち上げ方\n\n1. このリポジトリを clone する\n2. VSCode Dev Containers で開く\n    - 自動でコンテナのビルド、Extensions のインストール、 bundle install を行います。\n    - 数分かかるのでコーヒーを飲んで待ちましょう。\n\n## 使い方\n\n1. VSCode が起動したらターミナルを開き、下記のプロセスを立ち上げます\n    - `bundle ex rails s`: メインのサービスを起動\n2. 下記のようのPORTSタブを開いてください。\n    ![PORTS Tab](/docs/images/port.png)\n    - Local Addressに書かれているアドレスをブラウザで開くことを確認してください。この例では http://localhost:3001 です。\n    - Rails へリクエストが到達することと、ブラウザでRailsのログが開くことを確認してください。\n    - VSCode Docker Extension がコンテナ内で立ち上がったサービスを検知し、自動で Port Forwarding を行います。\n3. もう一つTERMINALを開きましょう。\n    ![TERMINAL Tab](/docs/images/terminal.png)\n\n4. この環境には [hey](https://github.com/rakyll/hey) というHTTPリクエストベンチを導入しています。新しく作成したTERMINALで `hey -n 4 -c 2 http://localhost:3000/posts` とコマンドを起動後、ブラウザで先程開いたURLを再表示してください。**ブラウザは60secほど読み込み中の表示になるはずです。**\n\n### なにがおきているのか？\n\nMain Service の起動時の表示は下記のとおりです。\n\n```shell\n=\u003e Booting Puma\n=\u003e Rails 7.0.4 application starting in development \n=\u003e Run `bin/rails server --help` for more startup options\nPuma starting in single mode...\n* Puma version: 5.6.5 (ruby 3.1.2-p20) (\"Birdie's Version\")\n*  Min threads: 2\n*  Max threads: 2\n*  Environment: development\n*          PID: 7209\n* Listening on http://127.0.0.1:3000\n```\n\n`Puma starting in single mode...` という表示から単一プロセスモードで起動しており、 `Min threads` も `Max threads` も `2` となっていることから、Main Serviceでは最大2リクエスト受け付けます。\n\n`hey -n 4 -c 2 http://localhost:3000/posts` は `Main Service` の `/posts` にリクエストを送るエンドポイントを、 `-c 2` で2並列を指定し、 `-n 4` で 4リクエスト送らせています。 `/posts` は下記の実装になっています。\n\n```ruby\n  def index\n    client = service_client\n    resonse = client.get('/')\n    # 便宜的に連携先サービスから取得してきたデータを表示する\n    render plain: response.body\n  rescue Faraday::TimeoutError =\u003e ex\n    render file: Rails.root.join('public/408.html'), status: :request_timeout\n  end\n\n  private \n\n  def service_client\n    if TIMEOUT.present?\n      Rails.logger.info(\"timeout: #{TIMEOUT} sec\")\n      Faraday.new(\n        'http://localhost:4567',\n        request: { timeout: TIMEOUT}\n      )\n    else\n      Rails.logger.info(\"timeout: 60 sec (default)\")\n      Faraday.new('http://localhost:4567')\n    end\n  end\n```\n\n`localhost:4567` は `Accident Service` が待ち受けています。このサービスは100sec sleepするため、Faradayのタイムアウトまで待ちます。試しに Main Service が起動しているターミナルに戻り、`SERVICE_TIMEOUT=10 bundle ex rails s` で起動後、 `hey` を起動していたターミナルで再度 `hey -n 4 -c 2 http://localhost:3000/posts` を実行し、ブラウザを再表示させてみてください。今度は**ブラウザは60secも待たずRailsのロゴを表示するはずです。**\n\nMain Serviceが Accident Service へのリクエストを、10secでタイムアウトするように設定しています。そのため、Main Serviceはブラウザのリクエストを受け付けると即座にレスポンスを返すことができました。\n\n今度は `RAILS_MAX_THREADS=4 bundle ex rails s` と指定しましょう。すると、同時に4リクエスト受け付けられる状態で起動します。先程紹介した `hey` コマンドを使って、同様のリクエストを送ってみてください。同時に2リクエストであれば、ブラウザのリクエストはレスポンスできているはずです。\n\n\nさて、EKSなどkubernetes環境ではPodがリクエストを受け付けられるかを確認するため `/ready` を監視することが多いです。このエンドポイントも `/` と同様にブラウザから叩いてみてください。リクエストを受け付けられるPodが減ってきたことをEKSが検知すると、自動でPodの数を増やしますが、これにも限度があります。いずれはMain Serviceもリクエストがさばけなくなっていきます。連携先サービスの不調により、リクエストが詰まっていく動きが想像できたのではないでしょうか？\n\n### システム構成\n\n![System Digram](/docs/puml/incident-drill-timeout.svg)\n\n#### Main Service\n\n- `/`: Railsのロゴを表示する\n- `/posts`: Accident Service の `/` にリクエストを送るエンドポイント\n- `/ready`: このサービスがリクエストを受け付けられるか、Kubernetes 等から監視されるエンドポイント\n\n#### Accident Service\n\nSinatraで実装されたWebサービスです。 .devcontainer/accident-service/ 配下にコードがあります。\n\n- `/`: 100秒レスポンスを返さないエンドポイント。実装は下記の通り\n\n```ruby\n  get '/' do\n    sleep 100\n    'Hello world!'\n  end\n```","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkompiro%2Fincident-drill-timeout","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkompiro%2Fincident-drill-timeout","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkompiro%2Fincident-drill-timeout/lists"}