サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
elastic-infra.com
チーフエンジニアの加辺です。 今日は珍しいトラブルに出会ったので紹介します。 起こった問題 ある環境ではEC2によりサーバを運用しており、アプリケーションをデプロイサーバでビルドし、その成果物をアプリケーションサーバへコピーすることでデプロイとしていました。 ここで新規サーバを作成していたところ、一部のアプリケーションサーバで見慣れないエラーが発生し、アプリケーションが起動しないという事象が確認されました。調べたところ、デプロイサーバはt3、アプリケーションサーバはt3aファミリーが利用されていることがわかり、アプリケーションサーバをt3ファミリーへ変更したところ、問題が発生しなくなることが分かりました。 さて、これはどのような機序によるものでしょうか。 調査 記事タイトルで答えをほとんど書いてしまっていますし、t3, t3aを知っていれば明らかですが、これはIntelとAMDの違いです。
チーフエンジニアの加辺です。 今回はterraform愛好家のためのメモ書きみたいなものです。 MySQL 5.7互換を謳っているAurora MySQL Compatible v2(以下Aurora v2と略します)ですが、具体的に作成するときにはパラメータの組み合わせがなかなか容易ではありません。 planは通ったけど実際にapplyしてみるとエラーであったり、いつまで経ってもクラスタが作成されなかったり… そんな憂き目を見る人(含将来の自分)を減らすため、この記事を書くことにしました。 ちなみに大抵の場合、目にするエラーはこれです InvalidParameterValue: The engine mode provisioned you requested is currently unavailable. 一番大事な設定: engineとengine_version まず前提とし
チーフエンジニアの加辺です。 Elastic Infraでは普段のコミュニケーションにSlackを、タスク管理にBacklogを採用しています。 そうするとBacklogの更新通知をSlackで受けたくなるのですが、BacklogはSlackとの連携機能を提供していません… (Typetalkがあるからという大人の事情でしょうか…?) 事情はともあれ、Backlogはwebhook機能を提供しています。 これによりプロジェクトのアクティビティを外部に送信(JSON POST)することができるわけです。 今回はこれを利用してBacklog上での動きをSlackに通知することにしました。 基本アーキテクチャ 今回はu-minorさんのQiita記事を参考にし、API Gateway + Lambda( + DynamoDB)で実現することにしました。 ソースコードも公開されているのですが、あえ
こんにちは、エンジニアの伊藤です。 今回は PostgreSQL のクエリ解析の話をします、と一口に言っても範囲がまだ広いので、まずは対象読者の絞り込みをさせていただきます。 本記事の対象読者 AWS RDS DB の利用者である 解析対象は、AWS Aurora for PostgreSQL ではない 解析対象は、AWS RDS for PostgreSQL だが、やんごとなき理由で Version 10 ではない これでわりと絞り込まれたと思います。すべて YES ならば続きをご覧ください。 ちなみに、AWS Aurora for PostgreSQL or AWS RDS for PostgreSQL Version 10 をご利用の方は、Performance Insights をご覧いただくことをオススメします。いい機能です。 事前準備 Parameter Group の設定変更
エンジニアの伊藤です。 前回の記事で、弊社和田よりAWS ECS (Fargate) を紹介いたしましたが、今回は実際に AWS ECS (Fargate) 上で Application を稼働させた際にチューニングポイントとなった箇所を紹介いたします。 この記事で取り上げるモデルケースはシンプルにこれだけです。 Web Server ECS Task 1 = nginx ECS Task 2 = puma + Ruby on Rails RDBMS Amazon Aurora MySQL ご自分でチューニングされる方を前提に話を進めていきますが、弊社では本記事で紹介する対応をサービスとして提供しておりますので、ぜひご活用ください! 一番お伝えしたかったことは書けましたのでもう思い残すことはありませんが、始めていきます。 ポイントは他の言語や Web Application Framew
(*1) ECS_RESERVED_MEMORY=512 として、メモリの 512MB は Amazon ECS コンテナエージェントが利用する想定です (*2) cpu の項目は unit 数になります。vCPU 2 であれば 2048 まで指定が可能になります。 タスクのサイズを変えたい すでに EC2 インスタンスのリソースをフルに使っていますので、 例えば ECS task1 にmemory を 3.5GB 割り当てたい、という場合は、 EC2 インスタンスをスケールアップ、あるいはスケールアウトして余剰リソースを出すような形になります。 また、 4GB など EC2 インスタンスのリソースを超えるタスクを起動したい場合もスケールアップが必要です。 スケールアップ スケールアウト deploy したい deploy 時は、既存タスクと同じ数のタスクが起動して、 ELB に組み込まれ
チーフエンジニアの加辺(a.k.a. limitusus)です。 みなさん、自己署名証明書(いわゆるオレオレ証明書)使ってますか? 今回お客様から クライアント証明書による認証機能を実現してほしい(自己署名証明書でOK) という要望がありました。 そこで実際にどうやったら運用できるかを考え、実際に構築してみたのでご紹介します。 そもそもなぜ自己署名証明書なのか 無料でのTLS証明書発行サービスとしてはLet's Encrypt(ACME)やAWS Certificate Manager(DNS認証)が多く使われていますね。 これらの登場で2016年頃からサーバ証明書用途での利用はほぼ絶滅したのではないかと思います。 しかしながらやんごとなき事情でTLSクライアント証明書認証をすることになってしまった場合はどうか。 クライアント証明書を無料で発行してくれるサービスというのは今のところなさそう
Elastic Infraは、AWS(Amazon Web Services)やGCP(Google Cloud Platform)などのIaaSを利用したサーバの構築・移行・運用、及び支援を行うサービスを提供しております。 安定運用の実現に加え、常に新技術にも目を向けさらなる効率化に取り組んでおります。基盤周りの最適化はもちろん、時にはアプリケーションコードにも足を踏み入れてのご提案を行うこともあります。 豊富な経験と技術力を持ったSREが貴社をチームでサポートし、お客様に安心して開発に注力して頂ける環境をご提供いたします。
このページを最初にブックマークしてみませんか?
『インフラ周りの総合支援サービス』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く