PlantUMLによってコードベースでAWSのアーキテクチャー図を作る方法 - Qiita
AWS上にサービスを構築するうえで、アーキテクチャー図を作る機会はままあるかと思います。 その際、draw.ioやCacooなどのウェブサービスで作っている人も多いのではないでしょうか。 今回は別のアプローチとして、PlantUMLによってコードベースでAWSのアーキテクチャー図を作る方法をご紹介します。 PlantUMLの実行環境を用意 まずは、PlantUMLの実行環境を用意します。 ローカル環境にインストールするのもいいですが、素早く試したい場合はPlantUML Web Serverを使うのが便利です。 AWSのアイコンセットを用意 PlantUMLでは、ファイルパスやURLを指定してリソースをインポートすることができます。 これにより自作の画像を組み込むことができるわけですが、ありがたいことにAWSが公式にPlantUMLのためのアイコンセットを配布しています。 awslabs/
【早めに準備を！】2020年にAmazon Relational Database Service (RDS)/Amazon AuroraでSSL/TLS証明書をアップデートする必要が生じます | DevelopersIO
先日のDevelopers.IO 2019 TOKYOのランチ時に出てきたお弁当の中身が、実質1/2白米という半ライス状態だった事に驚きを隠せませんでした。え？半ライスってそういう事じゃなく？ ▲ でも美味しかった 「うーん……白米とおいなりさんで米がダブってしまった」と脳内で呟いていた、AWS事業本部のShirotaです。ご飯に甘いもの、と聞くとちょっと気後れしてしまいますがおいなりさんは大好きです。 2020年3月5日、RDSで利用しているSSL/TLS証明書が期限を迎えます さて、見出しの通り 2020年3月5日 、現行のRDSで利用されているSSL/TLS証明書(CA証明書)が期限を迎えます。 現行のCA証明書は rds-ca-2015 となっている筈で、RDSのコンソールの「Connectivity& security」欄から確認できます。 この証明書の期限が切れる為、AWSでは
AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio | DevelopersIO
こんにちは、大阪オフィスのかずえです。10/11に、弊社は Developers.IO 2019 in Osakaを開催いたしました。お越し下さった皆様、ありがとうございました！ 私は今回、「AuroraかRDSどちらを選ぶべきか」というタイトルで登壇させていただきました。このエントリはその内容をブログ用にアレンジしたものになります。 ゴール AuroraとRDSの違いを理解して、 適切に使い分けることができるようになる もくじ RDSとは Auroraとは� RDSとAuroraの違い� アーキテクチャの違い� Auroraにしかない機能� RDSかAuroraどちらを選ぶべきか� Auroraを使えないケース� (Auroraも使えるけど)RDSを使うべきケース� まとめ� 登壇資料� 参考資料� RDSとは 皆さんご存知かと思いますが、RDSはAmazon Relational Da
サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019
原 康紘 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。本セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える Envoy の詳細にも触れながら、皆さまがサービスメッシュを活用する手助けとなるヒントを紹介します。 AWS の詳細については http://aws.amazon.com/jp
AWS Well-Architected Toolが日本語をサポートしました(東京リージョンでご利用いただけます) | Amazon Web Services
Amazon Web Services ブログ AWS Well-Architected Toolが日本語をサポートしました(東京リージョンでご利用いただけます) 私たちが、2015年に発表したAWS Well-Architected フレームワークは、クラウドにおけるシステム設計・構築・運用において、設計原則と「運用の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コストの最適化」の5つの柱を使用して、ガイダンスとベストプラクティスを提供するものです。 さらに2018年にはAWS Well-Architected Toolをリリースし、お客様のワークロードがAWSアーキテクチャの最新ベストプラクティスに則っているか、どのようなギャップがあって、どのようなリスクや改善点があるかを自分自身でご確認いただけるようになりました。このツールは昨年のリリース以降、すでに世界中で何万ものワー
AWS Elastic beanstalkからAmazon EKSへ移行する - 一休.com Developers Blog
以前の記事でも簡単に紹介した通り、一休では、アプリケーションのAWS Elastic beanstalkからAmazon EKSへの移行を進めています。 user-first.ikyu.co.jp この記事では、その背景や、実際の設計、実際にAmazon EKSを活用してみて気付いた点、困った点、今後の展望を紹介したいと思います。 AWS Elastic beanstalkの辛い点 新しい環境の構築や運用が大変 一休ではAWSのリソースをTerraformを使って管理しています。新しくウェブアプリケーションを立ち上げて、Elastic beanstalkで動かす場合、以下の作業をする必要があります。 Terraformで、Elastic beanstalkの定義を作ってリリースする。 新しいアプリケーションのデプロイを通知するように自前で作ったAWS lambdaを修正。 アプリケーション
Summary of the Amazon EC2 Issues in the Asia Pacific (Tokyo) Region (AP-NORTHEAST-1)
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
AWS 東京リージョンで発生した大規模障害についてまとめてみた - piyolog
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間（EC２） 約６時間 2019年8月23日 12時36分頃～18時30分頃（大部分の復旧） 障害発生時間（RDS） 約９時間半 2019年8月23日 12時36分頃～22時5分頃 障害原因（EC２） 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン（AP-NORTHEAST-1）の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊４データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
RDS for MySQL5.6 から Aurora（MySQL 5.6 互換）へ移行しました - Feedforce Developer Blog
ソーシャルPLUS 開発チームでインフラエンジニア をやっています id:mayuki123 です。気づけば入社から10ヶ月ほど経っていました。 ソーシャルPLUSのメッセージ機能については1年半ほど前にAurora移行を実施していますが、2019年2月中旬にメインのソーシャルログイン機能で利用している データベースをRDS for MySQL5.6からAmazon Aurora(MySQL 5.6 互換）に移行することが出来ました。 developer.feedforce.jp Auroraに移行する利点等は多くの方がまとめているかと思うので、今回はデータベース移行で実施した手順に着目して書こうと思います。 準備期間と移行作業の概要 データベース移行方法の選択 AWSのDMSとは AWSのDMSのリソースについて データロードの種類 新しいAurora環境の構築 データベースインスタンス
2019年のAmazon Prime Day。AWS上の42万6000台相当のサーバや1900個のデータベースインスタンスなどで乗り切る
2019年のAmazon Prime Day。AWS上の42万6000台相当のサーバや1900個のデータベースインスタンスなどで乗り切る Amazonは毎年、プライム会員向けのセールである「Amazon Prime Day」を開催しています。2019年のPrime Dayも、7月15日と16日の2日間行われました。 Amazon Prime Dayは世界各国で同じ日に行われているため、国ごとの時差はあるものの開催期間中はものすごい勢いでプライム会員がAmazonのECサイトにアクセスを繰り返します。Amazon Prime Dayが世界最大級のオンライントランザクションが発生するイベントであることに異論を唱える人はいないでしょう。 そのECサイトの基盤を支えているのがAmazon Web Services（AWS）です。 AWSのチーフエバンジェリストJeff Bar氏は、ブログ「Amaz
スタートアップのためのコンテナ入門 – 導入編 | Amazon Web Services
AWS Startup ブログ スタートアップのためのコンテナ入門 – 導入編 こんにちは、スタートアップ ソリューションアーキテクトの松田 (@mats16k) です。 今回はコンテナのお話です。今日、多くのスタートアップのお客様が本番環境でコンテナを採用し、ビジネスに活かしております。その一方で、「そろそろコンテナやった方がいいか？」「なんとなく使い始めたけれどこれでいいのか？」「コンテナ自体は分かったけど、サービスでの利用に踏み切れていない」といったご相談も数多く頂いております。 本記事ではコンテナ技術のサービス利用を検討されている方向けに、AWS 上でどうコンテナ化を進めていけばいいのかをお話致します。 目次 コンテナとは コンテナオーケストレーション コンテナ利用時・検討時によくある誤解 コンテナへの移行ステップ コンテナとは まずはじめに改めてコンテナ技術についての復習です。
AWS Transit Gateway はじめました - Hatena Developer Blog
AWS Transit Gateway とは? 構成検討 構成変更手順 事前作業 使用する TGW を作成する TGW に接続する VPN と VPC をアタッチする AWS VPC に TGW を参照する Route Table を作成する 当日作業 AWS VPN を TGW の Route Table にプロパゲートする VPC を TGW の Route Table にプロパゲートする VPC の Route Table に TGW 向けの経路を設定する AWS Classic VPN の VPN トンネルを落とす AWS Transit Gateway で知っていると良いこと AWS Transit Gateway をクロスアカウントで使う時に気をつけるポイント AWS Transit Gateway における Attach / Propagate / Associate という
AWS Lambda CI/CD俺的ベストプラクティス - くりにっき
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
Amazon SQSでFIFOだからってシステム全体が Exactly-Once になると思ったら大間違いだっていう話 - Smoky God Express
TL; DR Amazon SQS で Exactly-Once なキューを使おうとも冪等な処理を書くべき キューが Exactly-Once であるという性質はシステム全体が Exactly-Once になることを保証できない 結局マルチデータソースへの書き込みの問題が残る Designing Data-Intensive Applications (邦訳: データ指向アプリケーションデザイン） が良書でした 邦訳は未読1ですが原著の内容がいいのできっとだいじょうぶでしょう Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 作者: Martin Kleppmann出版社/メーカー: O'Reilly Media発売日: 2017/
Amazon S3 アップデート — SigV2 の廃止時期、延期と変更 | Amazon Web Services
Amazon Web Services ブログ Amazon S3 アップデート — SigV2 の廃止時期、延期と変更 Amazon S3 API に対して行うすべてのリクエストは、それが本物であることを確認するために署名する必要があります。初期の AWS では、署名バージョン2 または SigV2 と呼ばれる署名モデルを使用していました。2012年には、より柔軟な署名方法である SigV4 を発表し、2013年以降に開始されたすべてのリージョンでは、こちらを唯一の署名方法としました。また、その時点で、すべての新しい S3 アプリケーションにこちらのSigV4を使用することをお勧めしました。 2018年に、我々はSigV2のサポート終了を2019年6月後半とするという発表をしました。多くのお客様がアプリケーションを更新してくださいました（多くのケースで単純にSDKのアップデートを行うだけ
ソニーミュージックが音楽の権利情報処理システムにAmazon Managed Blockchainを採用
Amazon.com, Inc.の関連会社であるアマゾン ウェブ サービス ジャパン株式会社は、本日、株式会社ソニー・ミュージックエンタテインメント（以下、SME）が、音楽権利情報処理を容易かつ効率的に行うためのシステム基盤にアマゾン ウェブ サービス（以下、AWS）の、Amazon Managed Blockchainを採用することを発表しました。 昨今、楽曲などの様々なデジタルコンテンツを作成するツールが安価に手に入ることや、それらを発表できるインターネット環境が整備されたことから、誰でもコンテンツを創作、販売できるようになりました。それに伴い、クリエイターの活動の幅が広がり、コンテンツの権利処理業務に大きなリソースが割かれ、生産性の低下を招き、コンテンツ創作が阻害されている状況が生まれています。 SMEは、音楽クリエイティブの生産性向上に貢献することを目指し、クリエイターにとって重要
Pragmatic Terraform on AWS - KOS-MOS - BOOTH
『Pragmatic Terraform on AWS』では、Terraformを使ってAWS上にシステムを構築するノウハウを、100以上のサンプルコードとともに紹介します。ECS Fargateなどのマネージドサービスを中心にアーキテクチャ設計を行い、Terraformで実装します。サンプルコードはGitHubでも公開しています。ぜひ手を動かしながら一緒に学びましょう。 こちらは『Pragmatic Terraform on AWS』のダウンロード版です。技術書典6にて頒布したものと同様のものになります。 無料サンプル版もありますので、こちらもあわせてご覧ください。 ・ https://kosmos.booth.pm/items/1306706 ファイル構成zipファイルを解凍すると4つのファイルが出てきます。ご自身の環境にあわせて、好きなファイルをご利用ください。 ・Pragmatic
「Pragmatic Terraform on AWS」を読んだ - asmsuechan’s blog
ダウンロード版で読みました。 booth.pm 本の情報 項目 情報 ページ数 144P 章数 全22章 著者 @tmknomさん 全体的な感想 大事なのはTerraformの使い方というよりAWSのリソースを正しく構成して関連する全てのリソースの存在を明確に意識する力だと思いました。難しい。 最後の章に書いてある参考文献もとても素晴らしくて、SREとしてやっていきたいなら必要な知識が書かれている本ばかりですのでぼちぼち拾って読んでいきたいです。 ↓読んでいて心に残った言葉 Terraform で試行錯誤するときには、ケチケチせずにそれなりのインスタンスタイプを使用しましょう。時は金なりです。 こんな人におすすめ サーバーサイドは書けるけどWebインフラはちょっとあんまりって人は読んでとてもためになると思います。 この本を買った理由 Terafformを1から自分で書くという経験をしたこと
AWSアカウントを作ったら最初にやるべきこと ～令和元年版～ | DevelopersIO
はじめに 中山（順）です 4年ほど前にこの記事のタイトルと同じテーマで資料を作成したことがあるのですが、古い内容があったり新しいサービスのことが含まれていなかったりするので改めてまとめてみました。令和だし！ その時の資料はこちらです（クラスメソッドにジョインするくらい2年前です）。 AWSアカウントを作ったら最初にやるべきこと サインアップ （業務利用の場合）非個人メールアドレスでサインアップ サポートプランの確認 ID管理 / 権限管理 CloudTrailの有効化 ルートアカウントのMFA設定 IAM User / IAM Groupの作成 パスワードポリシーの設定 GuardDutyの有効化 Security Hubの有効化 請求 IAM Userによる請求情報へのアクセス許可 支払通貨の変更 Budgetの設定 Cost Explorerの有効化 Cost Usage Report
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unpublished Event
