AWS Compute Blog Using Amazon EFS to Persist Data from Amazon ECS Containers My colleagues Jeremy Cowan and Drew Dennis sent a nice guest post that shows how to use Amazon Elastic File System with Amazon ECS. — Docker containers are ideal for building microservices because they’re quick to provision, easily portable, and provide process isolation. While these services are generally ephemeral and s
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon Elastic File System で Elastic Beanstalk を使用する Amazon Elastic File System (Amazon EFS) では、複数のアベイラビリティーゾーンのインスタンスにマウントできるネットワークファイルシステムを作成できます。Amazon EFS ファイルシステムは、セキュリティグループを使用してデフォルトまたはカスタム VPC にあるネットワーク経由でアクセスを制御する AWS リソースです。 Elastic Beanstalk 環境では、Amazon EFS を使用して、ユーザーがアップロードまたは変更したアプリケーションのファイルを保存する共有ディレクトリを作成できます。アプリケーションは、
システム管理者は多くのサーバから随時データを受信してその健康状態を判断しなければなりません。サービスの負荷があがっていないか、ストレージは十分にあるか、データベースがボトルネックになっていないかなど判断材料は多数あります。 そうしたデータを逐一サーバにログインして確認していては時間がかかってしまいますので、データダッシュボードソフトウェアが使われます。今回はその一つ、Grafanaを紹介します。 Grafanaのインストール Grafanaのインストール方法は幾つも用意されています。CentOS/Ubuntuなど各Linuxディストリビューションごとにパッケージも提供されていますし、Dockerを使ったインストールも行えます。 # macOSの場合 brew update brew install grafana brew services start grafana # Dockerの場
Dockerではコンテナ内で実行されたプロセスの出力をログとして記録しておく機能が用意されている。このログ出力機構では、さまざまなログ記録システムにログを転送することが可能であり、複数の異なるホストで稼動しているコンテナのログを1つのマシンに集約する、といったこともできる。今回はこのログ機能について紹介する。 DockerのLogging Driver機構 Dockerコンテナでは、コンテナ作成後にコンテナ内のファイルシステムに書き込まれたデータはコンテナの削除時に一緒に破棄されてしまう。そのため、各種ログやエラーメッセージ出力などの保存しておきたい情報はコンテナ外に出力して保存しておく必要がある。Dockerではこれを支援する機能の1つとして、ログを外部のログ記録ソフトウェアに転送する機構が用意されている。これを利用することで、多数のコンテナが稼動するような環境や、複数のマシンを組み合わ
先日のブログ記事、Microsoft Active DirectoryユーザーのSimple ADへの移行方法で述べたとおり、AWS Directory ServiceによってSimple ADと呼ばれるスタンドアロンの高可用性のあるAWSマネージドのディレクトリを数分のうちに作成することができるようになります。Simple ADでは、Amazon EC2インスタンスがドメインに参加するためのユーザーアカウントとグループのメンバーシップを集中管理することができます。さらに、単一の認証情報ですべてのEC2インスタンスへのログインやアプリケーションへの認証ができるようになります。Simple ADに関する追加情報は、What is AWS Directory Service Simple AD?を参照してください。 先日の記事では、Microsoft Active DirectoryからSim
AWS re:Invent 2016で発表された、ビジュアルワークフローを用いて分散アプリケーションを構築するサービス『AWS Step Functions』。このフレーズのみだと雰囲気何となくわかりますが、もう少し理解を深めてみたいと思います。という事で、公式サイトにある説明文を読み進めて見ました。 AWS Step Functionsとは AWS Step Functionsを使うと、ビジュアルワークフローを用いて分散アプリケーション及びマイクロサービスのコンポーネントを容易に調整する事が可能となります。個別の機能を実行する個々のコンポーネントからアプリケーションを構築する事で、アプリケーションの拡張と変更を素早く行う事が出来ます。Step Functionsは、コンポーネントを調整し、アプリケーションの機能をステップ実行する、信頼出来る方法です。 Step Functionsはアプリ
AWSで優れた設計をしているか?の質問と回答(コスト最適化編)「AWS Well-Architected Framework」 「AWS Well-Architected Framework」 昨年、AWSより「AWS Well-Architected Framework」というドキュメントが公開されました。この文書は、みなさんがより良いクラウドベース設計を評価改善し、設計によるビジネスへの影響についてより良い理解をするためのものです。AWSで良い設計をしているかを定義する柱として、4つの分野におけるベストプラクティスとガイドを定義し、一般的な設計指針について取り組みます。 今回はコスト最適化についての確認事項をご紹介します。 他の確認事項はこちらです。 AWSで優れた設計をしているか?の質問と回答(セキュリティ編)「AWS Well-Architected Framework」 AWSで
雪山ジャンキー渡辺です。 今年もクラスメソッド雪山部は絶賛活動中ですよ。 さて、少し前ですが、AWS NAT Gateway(以下、NAT Gateway)がリリースされました(【新機能】ついに登場!Amazon VPC NAT GatewayでNATがAWSマネージドに)。 NAT Gatewayは、プライベートサブネットからインターネットへの通信を実現する仕組みです(外向きのみ)。 今日は、このNAT Gatewayを利用するひとつのパターンを紹介します。 サブネットを構成する3つのパターン サブネットは種別として、パブリック・プライベート・プロテクトの3つの形態が選択できます。 外部アクセス可能なパブリックサブネット パブリックサブネットは、ルートテーブルがインターネットゲートウェイと関連付けられたサブネットです。 パブリックサブネットでは、インスタンスにEIPを付与する事により外部
みんな大好きElastic Load Balancing(以下ELB)は利用にあたっては細かい仕様に注意する必要があります。 2014年ELBにお世話になった人もそうでない人も2015年はもっとELBを活用するために、改めてELBの仕様や活用方法を振り返ってみましょう。 ※本稿の内容の多くは一度でもELBを使ったことがある方を想定しています。 ELBが得意なところ ELBはコスト効果良く高い可用性と拡張性をもつロードバランサーをサービスとして提供してくれるので、最初に利用するロードバランサーとしても、長く使うロードバランサーとしても優秀です。 ELBを活用するためのドキュメントがAWSから公開されています。未読の方は必ず目を通しておきましょう。 Best Practices in Evaluating Elastic Load Balancing ELBが苦手なところ ELBを利用する上で
はじめに こんにちは植木和樹です。AWSで提供しているロードバランサーサービス Elastic Load Blancing でProxy Protocolがサポートされました。 【AWS発表】 Elastic Load BalancingがProxy Protocolをサポート 本日は新機能の使用レポートになります。またEC2インスタンスからみてどのように通信内容が変わるのか知りたかったので、簡易Echoサーバを用意して比較的低レベル層で通信をみてみました。 Proxy Protocol対応でなにがうれしいのか? Proxy Protocolがサポートされたことにより、どのようなメリットがあるのでしょうか?上記AWSブログから抜粋すると、こういうことのようです。 本日までは、ELBはHTTP(S)のロードバランシングに使用される場合のみ、クライアントのIPアドレスを取得できました。(中略)
はじめに こんにちは植木和樹@上越妙高オフィスです。今回は題名通り「キャッシュしない」CloudFront設定を行ってみました。 CDN(Contents Delivery Network)であるCloudFrontにキャッシュさせないのって意味があるの?と思われるかもしれませんが、理由は色々あります。 基本キャッシュしてほしくないけど、一部のパス(CSSとか画像とか)は同じドメインでキャッシュさせたい LINEやTwitterでの告知するページだけキャッシュさせたいので、事前にCloudFrontは準備しておきたい パス毎にオリジンを変えたい(L7ロード・バランシングしたい) Amazon WAF使いたいけどキャッシュはしたくない(私の今回の目的です) ネットで調べると同じ思いの方は結構いらっしゃるようですね。 キャッシュしない cloudfront - Google 検索(2016/0
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Auto Scaling グループとインスタンスの CloudWatch メトリクスをモニタリングする メトリクスは Amazon の基本的な概念です CloudWatch。メトリクスは、 に発行される時系列のデータポイントのセットを表します CloudWatch。メトリクスはモニターリング対象の変数と考え、データポイントは時間の経過と共に変数の値を表します。これらのメトリクスを使用して、システムが正常に実行されていることを確認できます。 Auto Scaling グループに関する情報を収集する Amazon EC2 Auto Scaling メトリクスは、AWS/AutoScaling 名前空間にあります。Auto Scaling インスタンスから CPU やその
【新機能】Amazon Route 53 に[Calculated Health Checks]と[Latency Checks]が追加されました! こんにちは、せーのです。 今日はRoute 53に追加された2つのチェック項目をご紹介したいと思います。 Calculated Health Checksとは 今までヘルスチェックは1ドメインにつき1つ、割り当てられていました。しかしポータルサイトなどでは特集ページやユーザーページ等、複数のドメインを使用してコンポーネントを構築するWebサイトがあります。Calculated Health Checksを使用するとこのような複数のドメインをグループ化しANDやORでまとめてヘルスチェックすることができます。例えば3つのドメインから成り立つサイトを運営していてどれか1つのドメインでもヘルスチェックが通らなかったらアラートを上げる、ということも可
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く