Excel以外でネットワーク構成図を書きたくなったのでPlantUMLとnwdiagを試してみました。
インフラエンジニアなら誰しもExcelでネットワーク構成図を作成した経験があるのではないでしょうか？ 私はラクーンに就職する前に2社で働いた経験があるのですが、いずれの現場でもExcelの構成図を触る機会がありました。 そんなExcelのネットワーク構成図ですが、私は以下の点で不便に感じています。 図形の中のテキストを検索できない 図形の位置をそろえるのが面倒 構成図を更新したときなどに差分
インフラ
PCバックアップシステムを自作する
情シス担当のますいです。 万一に備えてクライアントPCのバックアップをとっておくことは重要です。OS標準のバックアップ機能、バックアップ専用ソフト、クラウドバックアップサービスなど多様な方法があり、企業ではそれぞれの予算や方針に沿った方法を採用していると思います。 自作の経緯 弊社では、1年前まで「Windows Server Essenetialsエクスペリエンス」の機能を利
bashのプロセス置換で遊んでみよう！
今回は意外と知らないかもしれないbashの「プロセス置換」という機能を紹介します。 UNIXでは「1つのプログラムは1つの機能にとどめ、フィルタとして動作できるようにせよ」という設計思想があります。 その言葉の通り、大抵のコマンドはパイプでつないでフィルタのように動作可能ですが、必ずしも理想的に設計されていない、もしくは仕様上できないコマンドもあります。 例えば、よく使う diff コマンドが
GlusterFSの導入とGeo-Replication
今回は分散ストレージのGlusterFSをご紹介します。 これまでNFSやiSCSI、ZFSなど様々なストレージ技術を扱ってきましたが、 まだ分散ストレージについては未経験でした。そこで今回はGlusterFSの導入をやってみることにしました。 GlusterFSについて GlusterFSはRedhatにより開発されている、ファイルシステムです。 簡単に仕組みを説明す
2017.9.27
Sisimaiによるバウンスメール解析の自動化
私は主にインフラの運用管理を担当しています。 今回は弊社でも利用している、"Sisimai" によるバウンスメール解析についてご紹介します。 大規模なメール配信を行っていると、ユーザのメールアドレス登録間違いや、メールアドレス変更の未通知などでバウンスメールが度々発生します。 少数であれば管理者がバウンスメールを確認し、対応を手動で行えばよいかもしれませんが、それ
2016.9.21
AWS LambdaとAPI Gatewayを利用し、PagerDutyのインシデント発生時にSlackに専用チャンネルを作成する #3
前回の記事ではPagerDutyのWebhookをLambda関数で受け、SlackのIncident専用のチャンネルを作成してメッセージをpostしたり、IncidentがResolvedになったら専用チャンネルをarchiveしたりするところまでご紹介しました。 大まかにまとめると、下記のシーケンス図のような仕組みになります。 しかし、専用チャンネル
AWS LambdaとAPI Gatewayを利用し、PagerDutyのインシデント発生時にSlackに専用チャンネルを作成する #2
前回の記事に引き続き、AWSのAPI Gateway経由でLambdaファンクションを呼び出し、Slackの APIを叩いて専用チャンネルを作成する手順を説明していきます。 前回の記事ではPagerDutyのWebhookをLambda関数で受け取るところまでご紹介しました。 これからLambda関数内でSlackのAPIをコールするための処理を記述することになり
AWS LambdaとAPI Gatewayを利用し、PagerDutyのインシデント発生時にSlackに専用チャンネルを作成する #1
当社ではサーバーやネットワークに障害が発生した際に、障害対応の担当者へ通知を行う手段としてPagerDutyを利用しています。 担当者が障害を認知した後は障害内容を調査し、必要に応じて開発者や責任者へエスカレーションを行うことになります。 障害の発生が平日の日中帯であれば関係者間のコミュニケーションに問題はないのですが、夜間・休日の場合は関係者がそれぞれ別の場所に居るこ
ローカルUnboundによる名前解決の冗長化の検証
こんにちは！はんだです。 今日はDNSサーバの可用性向上についてのエントリです。 DNSサーバの障害時の影響を防ぐ方法として、 単純にDNSサーバを複数設置して/etc/resolv.confに記入するという方法がありますが、 その方法には、タイムアウトの待ち時間という落とし穴があります。 /etc/resolv.conf nameserver 192.168.0.11
CORECを支える技術 ～ログ監視編～ fluentd-AmazonSNS連携
こんにちは。なべです。 CORECの開発を担当しています。 『CORECを支える技術 ～チケット駆動編～』に続き、『CORECを支える技術』シリーズの第2弾としてCORECのログ監視について書きたいと思います。 旧ログ監視の問題と対策 当初、CORECのログ監視はログ集約にくっつける形で始まりました。 ログ集約はログファイルを一定時間ごとにバックアップする仕組みで、各サーバーのログをfluentd
iptablesを利用してNATサーバを構築
弊社では本番リリース直前検証環境として、ステージング環境を利用しています。 この環境が古くなってしまったため、環境再構築を実施することになりました。 再構築する上で、今後のこともあるので再構築しやすい環境に切り替えることにしました。 構築上でポイントとなったのは以下の2つです。 本番環境はVMで稼働しているので、そのバックアップを活用するサーバ設定（ネットワーク設定など）はできる限
CORECを支える技術 ～チケット駆動編～
こんにちは。なべです。 CORECの開発を担当しています。 これから何回かに分けて、『CORECを支える技術』と題してCORECの開発について書いてみようかと思います。 今回はチケット管理と構成管理との連携についてCORECでの取り組みをご紹介したいと思います。 毎週リリースのサイクルを維持するためのポイントは自動化 CORECは2014年3月17日に初回リリースをしてから、80回を超え