タグ

ブックマーク / blog.father.gedow.net (19)

  • データセンターの思ひで | 外道父の匠

    今月、とうとうオンプレミス環境がその役割を終えたので、当たり障りのない範囲で思ひでを記録しておこうと思います。 だいたい 2002年 から運用が始まったので18年ほどの歴史でしたが、血と汗と…… 血と汗くらいですかね滲んでるのは。さぁ振り返りです。 大阪 私が参画した時にはインフラエンジニアというかサーバー担当者が既に1名おり、「サーバーやってみない?楽しいよ!」と言われて乾いた笑顔を返したのを覚えています。 当時は京都の極小ベンチャー企業で、なぜ最初が大阪のデータセンターだったのかは聞きませんでしたが、とある現地作業についていって、ハーフラック1台に1U2台が積載されていました。このへんは私自身かなりのペーペーだったので知識不足もあり記憶がかなり曖昧です。 平々凡々に運用していたある日、WEBサイトへのアクセスが途絶えました。 社長の「ねぇ、サイトに繋がらないんだけど」の一言が口火です。

    データセンターの思ひで | 外道父の匠
    y_uuki
    y_uuki 2020/03/28
  • ミドルウェア性能検証の手引き | 外道父の匠

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

    ミドルウェア性能検証の手引き | 外道父の匠
  • AWS ALBの運用豆知識 | 外道父の匠

    たいした諸事情なわけでもないですが、だいぶ更新を空けてしまいましたので、ささやかなことからコツコツと書いていこうかと思います。 今回は、ALB(Application Load Balancer)の運用で得られた豆知識の記録です。 暖機運転の豆知識 申請の必要性 ALBはトラフィックが増加しても自動的に拡張して対応してくれますが、急激に増加すると拡張が間に合わずにキャパシティオーバーとなって、ALBがエラーを返してしまう可能性があります。そのため、事前にこのくらい跳ね上がりますので暖めて馴染ませておいてください。ってのが暖機運転(Pre-warming)です。 基的には事前に申請して扱う仕組みですが、想定よりトラフィックが多くなり、エラーが多発し、数十分・数時間も解決しない場合もこの申請をすることがあります。この場合、ALBが自動拡張してくれない = 何か他に問題がある 可能性が高いので

    AWS ALBの運用豆知識 | 外道父の匠
    y_uuki
    y_uuki 2017/07/19
    参考になる
  • Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠

    Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の2つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな

    Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠
  • ドリコムを退職しました……弟子が | 外道父の匠

    世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 人には「退職エントリ書くね!」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4~5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン

    ドリコムを退職しました……弟子が | 外道父の匠
    y_uuki
    y_uuki 2016/04/17
    wakateinfraに来てほしい
  • systemd時代に困らないためのlimits設定 | 外道父の匠

    数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール/SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上

    systemd時代に困らないためのlimits設定 | 外道父の匠
  • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

    RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

    現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
    y_uuki
    y_uuki 2016/03/08
    このLambdaの使い方の発想はなかった
  • NetworkManager+dnsmasqで名前解決の耐障害性を向上 | 外道父の匠

    クラウド・インスタンスにおけるDNSサーバーの指定は、DHCPサーバーから情報を取得して利用するようになっています。具体的には dhclient が resolv.conf を上書きする感じですが、最近は NetworkManager さんがこの辺の面倒を見てくれるので、まともな構成 ってやつを考えてみました。 ドンピシャで正着に至ったというわけではないですが、ひとつの有効な手段として扱うことはできそうです。 目次 概要 NetworkManagerがない場合 NetworkManagerのデフォルトの挙動 dnsmasqを利用する 任意のDNSサーバーを追加する 起動時の設定として組み込む dnsmasqのForward方式 DNSキャッシュ 耐障害性 理想の挙動 概要 NetworkManager は必ずしも必要なわけではないですが、CentOS7 など新し目のディストリビューションで

    NetworkManager+dnsmasqで名前解決の耐障害性を向上 | 外道父の匠
  • Amazon Auroraを真に理解するための性能検証 | 外道父の匠

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

    Amazon Auroraを真に理解するための性能検証 | 外道父の匠
  • 2014年からはじめるAWSリンク集 | 外道父の匠

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

    2014年からはじめるAWSリンク集 | 外道父の匠
    y_uuki
    y_uuki 2015/05/11
  • 新卒インフラエンジニアを育成した話 | 外道父の匠

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

    新卒インフラエンジニアを育成した話 | 外道父の匠
    y_uuki
    y_uuki 2015/05/11
    すごい
  • 原因調査用Linuxコマンド | 外道父の匠

    サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 <追加したコマンド> * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot

    原因調査用Linuxコマンド | 外道父の匠
    y_uuki
    y_uuki 2014/10/17
  • Mackerel Meetup #1 Tokyo に参加したり使ってみた感想 | 外道父の匠

    はてなMackerel は気になっていたので登録はしていたのですが、ウチのお母さんがこのイベントに参加することになり、その勢いで俺と息子(4歳0ヶ月)もいくことになりました。 Mackerel Meetup #1 Tokyoを開催します! – mackerel.io ブログ そのため、あわてて実際に Mackerel を使ってみて感想をメモっておくとかしておいたのですが、懇親会ではずっと息子と遊んでいたので、こちらに考えたことを書くことにします。 イベントの内容 これについては早くもまとめてくれている方々がいるので、こちらをどうぞ。 Mackerel Meetup #1 Tokyo の感想まとめ #mackerelio – Togetterまとめ Mackerel Meetup #1 に行ってきました #mackerelio | こえむの編集後記 はてぶ発の監視サービスを中の人が語る!

    Mackerel Meetup #1 Tokyo に参加したり使ってみた感想 | 外道父の匠
    y_uuki
    y_uuki 2014/06/20
    参考になります。
  • Percona Server 5.5にて10秒間隔でDisk I/Oが重くなる問題 | 外道父の匠

    久しぶりに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を確認。ピーク時

    Percona Server 5.5にて10秒間隔でDisk I/Oが重くなる問題 | 外道父の匠
  • Fusion-io ioDriveの検討資料~運用設定編~ | 外道父の匠

    サーバ筐体 コネクタは PCI Express x16 ですが、必ずサーバベンダー経由の購入のため、どの筐体で利用するかはベンダーと相談することになります。 寿命検知 SNMP SNMP/SMI-S を利用して、予備領域の残量やこれまでの読み書き量の監視ができます。 ioManager GUIツールでの状態確認もできます。 デバイス・ファイルフォーマットの流れ デバイスの認識 iomemory-vsl パッケージを入れるとDuoなら /dev/fct0, /dev/fct1 として認識されます ioDriveの論理フォーマット ブロックサイズ4Kbyteとしています。-s オプションで実効容量をいじれますが、普通は不要です。

    Fusion-io ioDriveの検討資料~運用設定編~ | 外道父の匠
  • Fusion-IO ioDriveの障害例と調査方法 | 外道父の匠

    インフラエンジニアに永遠につきまとう、月曜出社直後の障害報告と調査依頼。 今回はioDrive搭載サーバのMySQLが急に落ちましたということで、調査してみました。 これまで、ioDriveは不滅です。的なことばかり書いていましたが、まぁいつかは何か起きますよね・・・ってことで、ホクホクしながらioDriveのネガキャン、ではなく、こんな障害例がありましたよ、こんな感じで調べましたよという紹介をします。 月曜朝のスタート地点 依頼主からもらった情報。 あるioDrive搭載サーバのMySQLが急に落ちました 障害時間は 2012/09/29 03:30 です ioDriveのマウント先 /fio が利用できない状態です もうこのサーバは使っていないので好きに調査してください 今回は無償で受けてあげました。 それでは調査開始! ドライバなどのバージョン確認 2.2.3 を利用していることを確

    Fusion-IO ioDriveの障害例と調査方法 | 外道父の匠
  • ulimitが効かない不安を無くす設定 | 外道父の匠

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

    ulimitが効かない不安を無くす設定 | 外道父の匠
    y_uuki
    y_uuki 2013/10/15
  • ドリコムのソフトウェア選択のお話 | 外道父の匠

    mixiのサーバOS移行のお話 – mixi Engineers’ Blog とその続編に触発されて、私の寄生先であるドリコムではどのように考え、何を選択してきたのか振り返ってみたいと思います。 こういう情報の公開は、確かにしないに越したことがない類のものかもしれませんが、年末ですし、当たり障りのない範囲で思い出エントリで締めくくろうかなと思い立った次第であります。 OSの選択を振り返る 2001年あたりから覚えている範囲でザッと振り返ると、 RedHat 7-9 FedoraCore 1-3 Debian 3-6 CentOS 4-6 という感じで、現在はDebian(5/6)とCentOS(5/6)を主流で利用しています。あとはたまにBtoB案件とかでWindowsServerやRHELもちょこちょこありましたが、今はないですね。 こういう選択をしていった理由は、 まずRedHat~F

    ドリコムのソフトウェア選択のお話 | 外道父の匠
  • これからはじめるインフラエンジニア 発表資料 | 外道父の匠

    新卒採用のイベントで『知的ヘンタイ六番勝負』というのをやっていまして、その『第三戦 大規模インフラ・解析勉強会』にてインフラについて話してよ、と人事オファーをいただきまして発表した次第でございます。 エンジニア志望とはいえ、不特定多数の人間に対してインフラの話と一口で言われても、誰が何をどれくらい理解してるのかわからないので厳しい案件ではありましたが、せっかく来ていただくので真面目に張り切った結果、質疑応答含めて1時間弱に渡る発表+風邪でノドが潰れた資料がこちらになります。 補足 新卒の方々に向けて これまで新卒の人に関わる機会がなく、インフラについてどの程度理解があるのか全くの不明でしたが、思っていたより勉強しているなという感触と、良いエンジニアになれそうな匂いを発している野郎も結構多かったな、という印象でした。 資料でも触れてますが、WEBエンジニアを目指した時に、何を武器に何エンジニ

    これからはじめるインフラエンジニア 発表資料 | 外道父の匠
  • 1