GitレポジトリのホスティングサービスGitLab.comは2020年の5月に 6TB あるPostgreSQL 9.6クラスターをたった2時間のメンテウィンドウ中に11.7へアップグレードしました。 GitLab.comのエンジニアブログに、このPostgreSQLのメジャーアップグレードプロジェクトが解説されていたので、かんたんにご紹介します。 How we upgraded PostgreSQL at GitLab.com | GitLab ポイント PostgreSQL 9.6から 11.7 へのメジャーアップグレード 2時間のメンテナンスウィンドウ内でアップグレード完了 データサイズは6TB DBクラスターは GCP 上の 12台の VM インスタンスで構成 クラスターはアップグレード用の8台とリカバリー用の4台に分割 pg_upgrade & ハードリンクでインプレースアップグ

中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ

水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと

西澤です。クラスメソッドに入社してからおよそ5年間クラウドの推進やAWS技術に関する支援をさせていただいております。この経験を何か形にしたいと思い、少し遅れてしまったのですが、Developers.IOイベントに乗じてまとめさせていただきました。 発表資料 資料はこちらにアップロードしております。 夜間に録音したので覇気が無い感じになってしまいましたが、動画はこちらです。 まとめ 「AWS設計でやりがちな失敗パターン」というタイトルで考え始めたのですが、もっともお伝えしたい点は、AWSを利用されるお客さまのマインドセットを変え、クラウドを活用できる組織に変わって欲しい、というところに集約できるかなと思います。技術的な問題以上に、考え方を変えられないこと、組織を変えられないことが、クラウド活用を阻害するアンチパターンになっていると思いました。 どこかの誰かのお役に経てば嬉しいです。

スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと セッション管理が必要なWebアプリケーションを使う場合でも､スティッキーセッションを利用しない方法を説明します｡また､ログをインスタンス内に保持しない方法やAuto Scaling化についても触れています｡ はじめに おはようございます､加藤です｡煽り気味なタイトルで申し訳ございません､念の為より詳細に記載しますが､スティッキーセッションを使っていなければApplication Load Balancer障害の影響を受けるのを防げたかもしれないという内容です｡ 今後同様の障害への対処として､このブログの対応は行う価値がありますが､これだけやっておけばOKという事では無い事をご理解ください｡ 2019年8月23日にAWS

発生原因 ap-northeast-1a(ID:apne1-az4) に設置されたELBのノードが、5XXのエラー応答を戻していました。 暫定対処 ELB(ALB) で利用していたAWS WAFの保護設定を一時的に解除、ELB_5XXエラーが抑制された事を確認しました。 対応経緯 14:20 チャットの通知より、DevloppersIOのブログ基盤から HTTP 5XX の発生している事を確認 14:30 ElasticBeanstalkのダッシュボードの「WARN」イベントより、HTTP 5xx の発生状況を確認 CloudWatchの ALB ダッシュボードより、HTTP 5XX の発生状況を確認 ALBのCloudWatchメトリックより、ELBに起因する「ELB_5XX」エラーである事と、 AZ別のメトリックより ap-northeast-1a(ID:apne1-az4)、アベイア

こんにちは。こむろです。 今年の札幌の夏はハードモードだ（湿気と暑さ） この先生きのこるためにエアコンが投入されました。 はじめに クラウドネイティブなアプリケーションを設計・構築・運用している皆さんは、普段どのようにアプリケーションやインフラの更新作業を行っているでしょうか。 順次インスタンスやコンテナを切り替えていくRolling Update？それとも環境を複製してDNS Routingの切り替えによるBlue-Green Deploymentでしょうか。他にも様々な方法があるかと思いますが、今回もまたBlue-Green Deploymentにおける実際の現場で発生した事象について報告したいと思います。 あまりネット上にもこういった情報が出てこないようなのですが、皆さんこういった問題は軽々とクリアされているのでしょうか。自分がポンコツなだけなのかととても不安にかられるばかりです。

こんにちは、小澤です。 みなさん、雑コラ作ってますか？ "雑"とはいえ、画像編集が必要になって自分にはハードルが高いんじゃないか？と思ってる人も多いかと思います。 そこで今回はWord, Excel, PowerPointなどのMicrosft Office製品を使って簡単に実現する方法を紹介したいと思います。 画像中の背景の透過機能 最近のOffice製品には画像の背景を透過する機能があります。 スライドに張り付けた画像を選択して、リボンのメニュー項目から「図の書式」を選択すると一番左に「背景の削除」という項目があります。 この「背景の削除」を選択すると、画像の背景にあたる部分が自動判定されて、紫になります。 この状態で「変更を保存」を選択すると、紫の部分が削除された画像となります。 背景が透過された状態となるため、より背面に画像を重ねると、以下のような状態になります。 透過領域を調整す

「Dockerって、結局中でなにやってんの？」 先日、以下のミートアップに参加して、LT登壇してきました。 Docker Meetup Tokyo #31 (初心者歓迎LT祭り＋KubeConCN報告) 自分はLTの一番手として、「雰囲気でコンテナ使っている 全ての人が読むべき 「コンテナ技術入門」の紹介」で喋ってきたので、それの登壇報告となります。 「コンテナ技術入門」は、Dockerコマンド一通り使えるようになってきたけど、もっとDockerやコンテナについて深く知っておきたいという方にはむちゃくちゃ有用なコンテンツなので、一度目を通して、実際に手を動かして試してみることをオススメします。 （祭） ∧ ∧ Y　 ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉     ｺﾝﾃﾅﾏﾂﾘﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ 講演概要 当日のセッションスライドはこちら。 この記事では、LTという時間枠の中

更新履歴 2013/04/15 16:00 ENIの変更(デタッチ/アタッチ)は現状、仮想マシンの1つ目のENIでは不可のため、[ENIとは]の最後の説明と[ENIを変更するユースケース]の該当する説明文を修正しました。 シリーズ2本目行きます! 目次はこちら 前回は、AWSのネットワーク機能であるVPCの概要とサブネットの構成とルーティングの基礎を紹介しました。今回は、サブネットに接続する仮想マシン(EC2インスタンス)のネットワーク設定として仮想ネットワークアダプタ、アダプタに付与するIPアドレス、MACアドレスに注目していきます。 と、その前に... 今さらではありますが、このブログ記事は筆者が独自に調査、検証したものであり、AWSが公式に公開していない情報である場合もあります。ですので、ブログの内容を業務で利用する場合は自己責任でお願いします。また、調査はAWS Managemen

ども、大瀧です。6月にNothing's Carved In Stoneの新譜が出ると聞いてテンション上がっている今の勢いを生かし、シリーズものにチャレンジしてみます。 シリーズの目次はこちら 前振り(読み飛ばし可) インフラエンジニアのみなさーん、AWS触ってますかー? 「うちのシステムはAWSを使っていない」、「AWSじゃない国産クラウドを使う予定」など、AWSの認知度は一般にはまだまだ低いのが現状だと思います。しかし、組織のインフラは今後遅かれ早かれ、オンプレミスだけでなくクラウド環境と合わせて付き合っていかなければならないことは明らかですし、先行しているAWSの技術が他のクラウド製品のコンポーネントに与えている影響も、実はとてつもなく大きかったりします。 現状、多くのクラウド製品では、クラウドで利用できる機能を説明するときに"●●版S3"、"●●版セキュリティグループ"というように