全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来

なんと前回の続きになります、懐疑的な漢ですよろしくおねがいします。 半分は掘り下げるべき部分があったこと、もう半分は試験方法の最適化をしたくなった欲望によるものございます。 目的 検証の掘り下げ 前回の結論を要約すると、こんな感じだったのですが Good 😄 平均的な性能は第6世代(Graviton2)は第5世代より1割ほど高い 費用が第5世代より20％ほど安い 多数スレッド数になるほど性能を発揮するっぽい（情報収集より） Bad 😧 第6世代は処理の得手不得手の差が激しい 特に暗号化の性能が低い 第5から第6に切り替える場合、向上するかどうかは処理内容による 自分AWSの犬じゃないですけど、こう見ると期待が大きめだった分、少しネガティブな印象を残してしまったかなと。思ったので一部を深堀りすることで、もう少し特徴を捉えていくことにしました。 試験の最適化 前回はキレて Phoronix

C5が一歩抜けた強さの割に全部 ECU=10 な時点でアレですが、さらに6g系は該当なしです。で、費用的には c5/m5 の比率と c6g/m6g の比率は同じ 86% です。 第５世代では、C5 はメモリが少ない分、安くCPUが高速だったので強い選択肢でしたが、第６世代ではメモリが少ない分、安い。だけになるので、C系を選ぶメリットがだいぶ弱くなりそうです。 単純に、14％安くしてc6gにするって考えよりも、14％高くしてメモリ倍の方がよくねっていう。そういうパターンのほうが多いんじゃないかと、いうだけで全然絶対じゃないですけど。 考えようによっては、AutoscalingGroupに複数のインスタンスタイプを指定するとき、c6g, m6g, r6g と混ぜてもCPU使用率の格差がAZ以外で起きづらくなるだろうから、扱いやすくなると言えなくもない。 vs C5 あまりに差が付きすぎて、自分

コロナ禍によって環境が変化して、約１年が経過しました。 特に何かあるわけじゃないですが、社会にとっては大きな、自身にとっては少々の転機になったので日記でも記しておきます。 在宅勤務 社の方針が、できるだけ出社しない～原則出社禁止などと変化しましたが、私は元々コミュニケーションを重視しない方なので、喜んで即在宅のみに切り替えました。 結果、１年間で出社したのは健康診断１回の数十分のみ。 デメリットは太りやすくなるくらいで、でも病気には一切かからなくなったので、意識的に運動して健康管理してれば他はメリットしかない。 コロナ禍の『禍』は憂うべきものですが、『禍』を除いた変化は正直なところ自分にとって理想的な環境をもたらしました。完全に作業がススムくん。 会議 自分の周りはカメラなしで参加する方を好むので、存在としては完全に名前と技術力だけになった。 前から知った顔と話すこともあれば、全く知らん人

インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk

年明けからAuroraに粘着し続けて４記事目、残りカスのような数値を記録しておきます。 RDS/Auroraは起動時間がそんなに早くないですが、スナップショットからの復元は特に遅いと感じたので、データ容量との関係を調べておきました。 スナップショットからの復元時間 いざという時・・・のためでもありますが、より機会が多いであろうテスト用に起動する時のためにも、何GBならだいたい何分で起動するのかを知っておくと、運用上健康的ですよね、ということで。Auroraの管理画面で、進行％を出してくれると最高なんですが、まぁそこまで要求するのもアレなんで、、（ﾁﾗｯ）ただデータを増やして起動するという、不毛気味な検証というかデータ採取をしてみました。 sysbench と INSERT ～ SELECT でデータ容量を倍増させてはスナップショットを取得。そして１つずつ起動時間を計測していきました。 起動

よく、Auroraを採用しました、安定しています、移行してよかったです！とか見かけますけど、 なんで快適なのかをちゃんとわかって使ってんのかこの野郎ッp(｀･ω･´ﾒ)q 俺も全然わかってねぇッ( ･`ω･´) ということで、今回もいい感じに飽きてきたAuroraです。Aurora。少々気になっていた、ALTER TABLE周りについて興味深い数値が取れたので、その共有で御座います候。 MySQL5.6互換 AuroraはMySQL5.6互換というけれど・・・ Q:「MySQL と互換性がある」とはどういう意味ですか? これは、現在お客様が MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは InnoDB スト

前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは３種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ

今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ

CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し

エンジニアになってかれこれ14年目、そのうちの多くをインフラエンジニアとして過ごしてきました。ドリコムが弱小ベンチャーの時代から始まり、上場を経て今に至るわけですが…… そんな私の経験を凝縮したような書籍 『たのしいインフラの歩き方』 を執筆しましたことを、ご報告させていただきます！ 本の概要 タイトルどおり、インフラ周りの歩き方について記したものであるため、これを読めば環境を構築できるとか、深い技術や仕組みを理解できる、というようなザ・技術書といった類の内容ではありません。 では、ここでいう歩き方とはなんぞや？といいますと、起業したての小企業から、数百人規模の大企業に至るまでに、どのような技術的要望があり、どのように解決していくのか、という時間軸や規模感に沿ったインフラのエンジニアリングや、その心構え、ということになります。 対象読者としては、大きくは初～中級者のエンジニアとなっています

お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から本番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は本人の希望以外に人事部判断や

ブログが流行りだして10年以上が経とうとしているのに今更な内容ですが、エンジニアがブログを書く書かないについて再考する機会があったので、書き留めておきたいと思います。 書く人にとってはメリットがわかってるし、書かない人にとってはデメリットを流せるし、ぶっちゃけ好きにすればいいだけではあるのですが・・・ アウトプットとは ”発信”の方がしっくりくるのでどっちも使いますが、ここでは一般的っぽい”アウトプット”としています。私が思いつくアウトプットとは、 技術ブログを書くこと Wikiに手順やバッドノウハウをまとめること Twitterやコミュニケーションツールで短文メッセージを投稿すること 登壇発表すること 講師やメンターとして育成すること 書籍や連載を執筆すること ソースコードを公開またはプルリクすること で、どれも社内／社外どちらでも問わない、といったところです。ただし、社内におけるコード

前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi

久しぶりにDBAとしてお手伝いした時の汚いメモになります。 Percona Server5.5＋ioDriveのMySQLで、イベント時やピークタイムにアプリケーションからのDB利用が重くなる、ということで調査から対応方法まで考えてみました。 問題点の大雑把な特定 高トラフィック時に、RubyからMySQLの接続やクエリがちょこちょこ重くなり、レスポンス速度に影響が出る、とのこと。で調査開始。今回のPercona Serverのバージョンは 5.5.34 でした。 top -d1 で触診してみると、謎の10秒間隔でiowaitが5～10％に上がることを確認 5分平均のiowaitグラフを見ても、ピーク時は50～60％であることを確認。ioDriveでこれはイカン dstat で見ると、平時はwrite数MB/s～十数MB/sのところが、やはり10秒間隔でwrite 数百MBを確認。ピーク時

最近うぇぶ業界では、開発効率や構築効率を求める動きが活発のように見受けられますが、ここで改善効率について手を伸ばしてみましょう。 改善効率とは、開発後期やサービス開始後の運用フェーズにおいて、クソコードやクソクエリ、データの蓄積によるレスポンスの悪化などを、自動的に検知し、開発者にオラオラ改修をプッシュするための仕組みのことでございます。 はじめに ここで紹介する内容はドリコムで実際に運用しているものですが、別にドヤ顔するようなものではなく、中規模以上の企業ならば似たようなことやそれ以上のことをやっているであろう、至極当然な内容です。それでも、それなりに種類が増えてきたことと、それなりの効果を得られていることが実感できているため、いったんまとめてみようと思った次第です。 ウチのサービスのサーバーサイドは Ruby on Rails + MySQL が基本なので、その対策手法になります。WE

ガチのAWSド素人が年末に調べまくった、AWS関連のリンク集です。 まだまだ調査中なので随時追加する予定ですが、広深くてキリがないのと、年始一発目の目覚ましエントリということでいってしまいます！ はじめた目的 多数のスタートアップにおいて、インフラ専門のエンジニアが付かなくても、小～中規模程度まではそのチームでインフラ面を完結できるようにしたい。 …ということで、今の時代に合わせて簡単・安価・拡張性・耐障害性…を満たす環境を考えるべく、ひたすら知識をかき集めることにしました。考えた構成などについては別途書きたいと思います。 また、遡って調べるほどに出来と進化速度に感心するとともに、情報消費期限がせいぜい２年だと感じ、ほぼ２年以内の情報をもってこのような臭ぇタイトルにしています。 目次 ドキュメント アーキテクチャ クラウド全般比較 クラウド性能比較 費用／スペック ネットワーク 基本インス

最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに

limits.conf に書いても ulimit に効いていない、というのはよくある話です。 ulimit が少なくて困ったことはあっても、多くし過ぎて困ったことはほとんどないでしょうから、ドーンと全条件下でulimit設定を効かせる方法を紹介します。 ulimitが効かない問題 だいたいこんな内容だと思います。 SSHログインだと効かない su すると効かない OS起動時に自動起動したデーモンに効かない 普通はデーモンに効けばよいので、本当に困ったら起動スクリプトに直接書いたりしますが、方法としてはイマイチなのでちょっと工夫をします。 その前に・・・ PAMについて PAMというユーザー認証システムについてはググっていただくとして、よく出てくる /etc/security/limits.conf という設定ファイルは、PAMを通る条件下でしか有効になりません。 ではPAMを通るとはどうい

ついつい CDH4.1 から CDH4.4 にアップグレードしてしまいましたので、手順を省いて注意点などを記しておきます。 機能的には What’s New in CDH4.4.0 まで見てもメリットよりリスク不安の方が高いのですが、Hadoop新担当者の運用鍛錬という名目でゴリッとやってもらって、私はその後ろで煽ってました。 手順について How to upgrade from CDH4.0 to CDH4.1 for Debian | 外道父の匠 と流れは同じで、 ジョブを止めて Hadoopを止めて アップグレードして Hiveメタストアを更新して 再開して動作確認する（ログ保存／ジョブ） だけなので難しいことは特にありません。 QJM HAも特になにもなかったです。 なので、細かいメモだけ書いておきます。 NameNode WARNログ 挙動に支障はないのですが、読み書き両方ともに