タグ

awsに関するyukungのブックマーク (101)

  • SwaggerでRESTful APIの管理を楽にする - Qiita

    背景 最近は変化し続ける要件に対応するために、システムも柔軟であることが求められています。 そのため、部分的に変更やスケールの可能なシステムを構築し、API経由で連携するマイクロサービス的アーキテクチャが増えてきています。 そういった設計の中で問題になっていくのが、従来のモノリシックなアプリケーションではIDEやコンパイラなどで行っていた、機能間のインターフェイスをどう管理するかという部分です。 Swaggerとは? SwaggerとはRESTful APIのドキュメントや、サーバ、クライアントコード、エディタ、またそれらを扱うための仕様などを提供するフレームワークです。 公式サイトでは、The World's Most Popular Framework for APIsと謳っています。 その理由は、マイクロソフト、Google、IBM、SmartBearなどを大手の企業を含む「Open

    SwaggerでRESTful APIの管理を楽にする - Qiita
  • Swaggerで始めるモデルファーストなAPI開発

    え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Technology & Innovation

    Swaggerで始めるモデルファーストなAPI開発
  • ECSのオートスケール戦略 - Carpe Diem

    概要 ECSはコンテナのスケールアウトとインスタンスのスケールアウトのタイミングが重要です。 よく起きる問題としては インスタンスのスケールアウトが遅くてコンテナのスケールアウトも遅くなってしまう しきい値が不適切でインスタンスがスケールアウトせず、コンテナがスケールアウトしたくてもできない で、こういった事が起きないようにしないといけません。 スケールアウトの方針 対象 方針 インスタンス インスタンスの空きリソースがコンテナ1台分だけの状態がn分間続いたら コンテナ コンテナの使用率がn%を超えたら インスタンスはもう1台もコンテナを追加するリソースがない状況になったら早めにスケールアウトします。 コンテナは一般的なやり方で使用率が高くなったらスケールアウトすればOKです。 スケールインの方針 対象 方針 インスタンス コンテナがn分間ずっと1台を下回ったら コンテナ コンテナの使用率

  • Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ | Amazon Web Services

    Amazon Web Services ブログ Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ 日よりAmazon EC2 Container Registry (Amazon ECR)で利用可能になったライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。 Amazon ECRはフルマネージドのDockerコンテナレジストリで、同時に何百ものプルを捌くための典型的なスケールの問題を心配することなく、Dockerコンテナイメージを保存し管理しデプロイすることができます。スケールの意味する所として、Amazon ECRを活発に利用している開発チームはしばしばたくさんのコンテナイメージのバージョンによってレポジトリが埋め尽くされていることを発見すること

    Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ | Amazon Web Services
  • NLBでfluentdのforwardパケットを分散させてみた - Qiita

    AWSの新しいロードバランサであるNLB(Network Load Balancer)を使ってfluentdのforwardパケットを分散してみたので、レポートをまとめておく。 NLB自体については、クラスメソッドのブログ等で紹介されているのでそちらを参照するのが分かり易い。 静的なIPを持つロードバランサーNetwork Load Balancer(NLB)が発表されました! 試してわかった NLB の細かいお作法 ざっくり言うと、TCPプロトコルを対象にしたALBって感じ。 ターゲットグループはポートレベルで設定できるので、コンテナ環境と相性が良い。 ポート違いで複数fluentdが立っていても同じグループとしてまとめて分散できる。 利用までの流れ ターゲットグループを作成し、TCPレベルでコネクションが貼れるかのヘルスチェックの設定をする インスタンスもしくは対象IPと、ポートの組を

    NLBでfluentdのforwardパケットを分散させてみた - Qiita
  • Get Ready for re:Invent 2017 Content Overview - AWS Online Tech Talk

    - Learn what to expect at re:Invent 2017 - Learn what's new and noteworthy at re:Invent 2017 - Learn to plan your time effectively at re:Invent 2017

    Get Ready for re:Invent 2017 Content Overview - AWS Online Tech Talk
  • AWSの負荷テストについて | Developers.IO

    はじめに AWSでは負荷テストを実施する際に事前申請は不要でしたが、 意図した負荷であってもトラフィック量によってはDoS/DDosとして検知されネットワークが遮断されることがありました。 そこでネットワーク遮断の回避の方法や負荷テストの可否について、 AWSへ確認しましたところ現在は負荷テストを行う際は実施前に承認を受ける必要があることがわかりました。 英文 (AWSより) All AWS users are required to receive approval before any load testing. Please send detailed plans of the testing including expected peak bandwidth to the simulated events email address listed on the AWS Penetr

    AWSの負荷テストについて | Developers.IO
  • IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO

    さて、皆様はIAMにどのようなイメージをお持ちでしょうか。プロジェクトに関わる複数人で1つのAWSアカウントを扱う時、各メンバーに配布するアカウントを作れる機能。そして、その気になればアカウントをグループ分けし、権限を厳密に管理できる機能。といったところかと思います。 上記のユースケースで出てきた主なエンティティ(要素)はUserとGroupですね。IAMのManagement Consoleで見てみると、IAMはこれらの他にRoleやIdentity Providerというエンティティによって構成されているようだ、ということがわかります。今日はRoleにフォーカスを当てて、その実態を詳しく理解します。 IAM Role IAM Roleを使うと、先に挙げたIAMのユースケースの他に、下記のようなことが出来るようになります。 IAM roles for EC2 instancesを使ってみ

    IAMロール徹底理解 〜 AssumeRoleの正体 | DevelopersIO
  • カジュアルにCloudFrontを使って動的コンテンツと静的コンテンツを振り分け - Qiita

    はじめに AWS WAFを適応した構成を提案する機会がありそうなので、WAFが適応しやすい構成でELBの前にCloudFrontを持ってきたインフラアーキテクトを試してみたかったので、そのまとめです。 今回の全体イメージ http://dxxxxxxxxxxxxx.cloudfront.net 静的コンテンツ表示(画像) http://dxxxxxxxxxxxxx.cloudfront.net/img/sumou.jpg 静的コンテンツ表示(PDF) http://dxxxxxxxxxxxxx.cloudfront.net/test.pdf CloudFrontのマルチオリジン設定 Origin Domainに以下の3つを登録する ELBのendpoint 画像用バケット PDF用バケット Behaviors設定 Path Patternで振り分け設定する ポイント S3のwebhosti

    カジュアルにCloudFrontを使って動的コンテンツと静的コンテンツを振り分け - Qiita
  • AWSにおけるSSL証明書の基本的な取扱い | 外道父の匠

    多くの企業が、今年中にWebサービスの暗号化を進めなくてはいけなくなったかと思います。 Webに接続するiOSアプリは2017年1月からHTTPSの使用が絶対条件になる、デベロッパーはご注意を | TechCrunch Japan ということで、基的な内容ではありますが、AWSにおけるSSL証明書の扱いについて復習してみます。 AWSで扱う証明書の種類 ここでいう種類とは、EV SSL だの ワイルドカードだの、証明書の製品としての種類ではありません。 1つは AWS Certificate Manager(以下、ACM)の無償証明書、もう1つは従来のSSLサーバ証明書販売サイトで購入する有償証明書、の2種類となります。 それぞれの証明書を、AWSのリソースにどのように登録し、運用していくかについてまとめていきます。 ACMの証明書を利用する 2016年1月にリリースされ、5月にはTok

    AWSにおけるSSL証明書の基本的な取扱い | 外道父の匠
  • The parameter Origin DomainName does not refer to a valid S3 bucket. - keiwt’s diary

  • Route 53でZone ApexドメインをS3を使ってリダイレクトする | DevelopersIO

    最近、Zone Apex *1ドメインに対するリクエストをリダイレクトしたいという要望があったため調査しました。その調査結果について記述します。 S3のStatic Website Hosting機能にはRedirect all requests to another host nameという選択肢があります。この機能とRoute 53のAliasレコードを組み合わせることでZone Apexとなるドメインに対するリクエストを簡単にリダイレクトすることが出来ます。今回は例としてhttp://hoge.example.com/へのアクセスをhttp://example.net/hoge/にリダイレクトする設定方法について記述します。 リダイレクトに利用するS3バケットを作成する まずS3のマネジメントコンソールでリダイレクトに利用するS3バケットを作成します。S3のStatic Websit

    Route 53でZone ApexドメインをS3を使ってリダイレクトする | DevelopersIO
  • S3のRedirection Rulesを利用してリダイレクトする | DevelopersIO

    前回からだいぶ経過しましたが、今回はS3のRedirection Rulesを利用してリダイレクトを行う方法について記述します。Redirection Rulesを利用するとパスやパラメータに関係なくS3バケットへのリクエストを特定のURLにリダイレクトすることができるようになります。 前回はS3のRedirect all requests to another host nameについて紹介しました。この機能はリクエストURLのパスやパラメータを引き継ぐため単純なドメインの移行をした際には有用です。例えばhttp://hoge.example.com/fuga?piyoへのアクセスはhttp://example.net/hoge/fuga?piyoへリダイレクトされます。 一方であるサイトへのあらゆるリクエストを特定のURLにリダイレクトしたいケースもあるかと思います。そのような場合に利

    S3のRedirection Rulesを利用してリダイレクトする | DevelopersIO
  • [AWS]ECSとALBを使ったパスに従ったルーティング | DevelopersIO

    コンニチハ、千葉です。 ALBのパスベースルーティングを利用すると、URLに従ったターゲットグループ(インスタンスのグループ)へルーティングできます。ECSも、こちらのパスベースルーティングに対応しているため試して見ました。 【新機能】新しいロードバランサー Application Load Balancer(ALB)が発表されました メリット 振り分けのイメージです。 このように1つのALB、1つのECSクラスター上で、ECSサービス(コンテナ群)に対しパスルーティングを行えます。これの応用ですが、以下のような構成も可能です。 Classicロードバランサー時代アプリケーションを分けるには、アプリケーションごとにロードバランサーを用意する、または1つのロードバランサーとアプリケーションごとにポートを用意するという構成しかありませんでした。 大きなメリットしてALBでは、ロードバランサー1

    [AWS]ECSとALBを使ったパスに従ったルーティング | DevelopersIO
  • Amazon EC2 Container Service(ECS)の概念整理 - Qiita

    概念図 とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。 図1 概念図 Serviceが中心 ECSは平たく言うと クラスター(=複数EC2インスタンスの集合)の上で Dockerコンテナを使って、 Serviceを動作させる ものです。 図2 例えばの構成 上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの) API Service (ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの) と言う2つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ

    Amazon EC2 Container Service(ECS)の概念整理 - Qiita
  • ACMに証明書をインポートしてお手軽に証明書利用 - サーバーワークスエンジニアブログ

    寒さもひとしお身にしみるころ、皆様いかがお過ごしでしょうか。 ブログでははじめまして技術4課の酒井です。 去る10月13日にAWS Certificate Manager(以降 ACM)にサードパーティのサーバ証明書がインポートできる機能が追加されました。 これによりこれまではマネジメントコンソールから確認できなかったAWSにインポートされたサードパーティのサーバ証明書の有効期限や利用状況などが確認できるようになりサーバ証明書の管理が非常に楽になりました。 では実際にインポートの手順についてみていきましょう。 サードパーティのサーバ証明書の取得 各社で様々な種類のサーバ証明書が用意されておりますので用途に合わせて取得しましょう。 注意点として複数台のサーバにサーバ証明書をインストールする場合やロードバランサやCDNサービスにインストールする場合、各ベンダーごとにサーバ証明書のライセンス形態

    ACMに証明書をインポートしてお手軽に証明書利用 - サーバーワークスエンジニアブログ
  • [ACM] COMODO発行のサーバ証明書をACMにインポートして利用してみた | DevelopersIO

    はじめに AWSチームのすずきです。 AWSが提供するACM(AWS Certificate Manager)のアップデートにより、 AWS以外の認証局、ComodoやSymantecなどが発行した証明書をACMにインポートし、 ELB、CloudFrontのHTTPS通信に利用する事が可能となりました。 今回、COMODOで発行されたサーバ証明書を、ACMにインポートする機会がありましたので、 紹介させていただきます。 Importing Certificates into AWS Certificate Manager Announcement: Announcing AWS Certificate Manager Support for Third-Party Certificates 事前準備 SSLサーバ証明書の発行は完了済みとします。 COMODO SSL > 申し込み更新ガイ

    [ACM] COMODO発行のサーバ証明書をACMにインポートして利用してみた | DevelopersIO
  • production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita

    実際には、まだ当の番環境では運用できてなくて開発用のステージングで運用が開始できたぐらいで、他にもやること一杯あるんだけど、ある程度知見が溜まったのでまとめておく。 ちなみに、規模はそんなに大きくないがデータ量は多いアプリケーションで運用環境はAWSのECSを想定しており、現時点で普通のEC2ノードとコンテナで並行稼動している。 docker-swarmなりで自前でコンテナプールを構築してもいいのだが、そうするとサービスディスカバリとか考えなければいけないことが増えるので、後回しにしている。 (注: かなりサービス固有の事情が含まれるため、もし参考にされる方が居たとしても、そのままの形では適用できない可能性が高い) 追記: RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita コンテナ化のモチベーション CentOSのお守りからの

    production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita
  • ECS を利用したオフラインジョブの実行環境 - クックパッド開発者ブログ

    技術部の鈴木 (id:eagletmt) です。 クックパッドでは以前からアプリケーションの実行環境として Docker を利用していましたが、最近は徐々に Amazon EC2 Container Service (ECS) を利用し始めています。 去年の時点での Web アプリケーションのデプロイ手法 *1 や、最近 ECS を利用してどう Web アプリケーションをデプロイしているか *2 については紹介したことがあるので、今回は定期的なバッチ処理やジョブキューを介して非同期に実行されるようなオフラインの処理について、どのような環境を構築しているか紹介したいと思います。 Docker を使う前 Docker を利用し始めるより前から社内では kuroko2 *3 というジョブ管理システムが稼動しており、複数のアプリケーションから利用されていました。 kuroko2 は定期的にジョブを

    ECS を利用したオフラインジョブの実行環境 - クックパッド開発者ブログ
  • なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する - Sweet Escape

    2020/01/20 Update: エントリの内容は2019年12月3日にアナウンスされた『Amazon RDS Proxy』のリリースにより完全に陳腐化しました。過去のアンチパターンがフィードバックをもとにした改善によってアンチパターンではなくなるという最高の事例です。 サーバーレス元年始まった! 今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから. ・カスタムランタイムで実質どんな言語でも利用可能 ・VPC利用時のコールドスタート改善 ・Provisioned Concurrencyでスパイク対応も可能 ・RDS ProxyでRDBとの接続が現実的に これまで5年で受けたフィードバックがついに結実. 強い— Keisuke Nishitani (@Keisuke69) 2020年1月19日 RDS Proxyの詳細はこちらからどうぞ。まだプレビューですがぜひ試して

    なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する - Sweet Escape