うるおい Animal ちいさな森の加湿器は効果はわからないけどなんかいい感じ

会社が乾燥して辛いので加湿器を導入したいのですが、コンセントに空きがない…
と諦めていたのですが電気の要らないいいかんじの加湿器をみつけたのでご紹介します。

うるおい Animal 小さな森

積水樹脂という会社から出ている「うるおい Animal 小さな森」という自然気化式の加湿器です。

これ一つでコップいっぱいの10倍の加湿効果があるようです。

積水樹脂 自然気化式ECO加湿器 うるおいちいさな森 エルク‐グリーン ULT-EL-GR

組み立ててみる

さて、実際に使用してみたいと思います。

箱を開けると中身はこんな感じ。
ボトルとフィルターとトレイが入っています。

まず、ボトルに水を入れます。

そしてトレイに逆さまにさします。

キャップには小さな穴が空いているのでトレイに水がはられます。

続いてフィルターを森の形にくり抜いていきます。
これが

こうなって

こうなります。
点線に沿って手でかんたんにくり抜くことができます。

そのくり抜いたフィルターを水で濡らして

トレーにさしたら完成です。

まとめ

正直効果の程はよくわかりませんが電気もいらないということと、見た目が可愛いのでおすすめです！

積水樹脂 自然気化式ECO加湿器 うるおいちいさな森 エルク‐グリーン ULT-EL-GR

Amazon Linux で snmpwalk を利用する

Amazon Linuxでsnmpwalkを利用しようとしたときにCommand not foundって言われたので簡易メモ。

インストール

sudo yum -y install net-snmp-utils

確認

snmpwalk -v 2c -c public localhost

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

Zabbixの監視でTimeout while connecting to "192.168.1.1:161"のエラーが出るときの対処法

Zabbixでホストを追加していてこんなかんじのエラーを見たことはないでしょうか？

今回はそんなZabbixの監視でTimeout while connecting to "192.168.1.1:161"のエラーが出るときの対処法についてご紹介します。

監視にZabbix Agentを利用している場合

Zabbix Managerをインストールしているサーバで以下のコマンドを実行します。

zabbix_get -s 監視先のIPアドレス -k agent.version

このコマンドを実行し、バージョンが取得できる場合できない場合には、Zabbix Managerと監視先のサーバのネットワークに問題がある恐れがあります。

/etc/zabbix/zabbix_agentd.confの記載を見直すか、ネットワーク機器の設定を再度確認しましょう。

監視にSNMPを利用している場合

監視にSNMPエージェントを利用している場合は、Zabbix Managerをインストールしているサーバで以下のコマンドを実行します。

snmpwalk -v 2c -c public 192.168.1.1 .

このコマンドを実行し、接続することができればSNMPで取得できる値の一覧が出力されます。

ネットワークに問題がある場合はタイムアウトのエラーが出力されます。
ネットワーク経路に問題がないか、SNMPのリクエストを許可していないかなどを疑ってみましょう。

改訂版 Zabbix統合監視実践入門 ~障害通知、傾向分析、可視化による省力運用 (Software Design plus)

Zabbix3.0でWindows Server 2016 をSNMPエージェントで監視する

Zabbix3.0でWindows Server 2016 をSNMPエージェントで監視する方法をご紹介します。
Windows Server 2016にSNMPサービスをインストールする方法については以下の記事を参照ください。

www.kabegiwablog.com

環境

• Zabbix 3.0
• Windows Server 2016

手順

Zabbix Serverにホストを追加する

ブラウザでZabbixにログインし、上部メニューから「設定」をクリックし、「ホスト」を選択します。

「ホストの作成」を選択します。

「ホスト名」「グループ」を任意に設定します。
「SNMPインターフェース」に監視するWindows ServerのIPをアドレスを入力します。

「テンプレート」を選択し、新規テンプレートをリンクの「選択」ボタンを押下します。

テンプレートの一覧が表示されますので「Template SNMP OS Windows」にチェックをいれ、「選択」ボタンを押下します。

新規テンプレートをリンクの枠の中にある「追加」をクリックします。

下の「追加」ボタンを押下します。

2分くらい待つと「エージェントの状態」の「SNMP」の欄が緑色になりますのでそれで監視設定は完了です！

まとめ

Zabbixエージェントを利用する場合と比べて少し面倒ですがSNMPを利用しても監視を実施することが可能ですので検討してみるのもいいかもしれません。

改訂版 Zabbix統合監視実践入門 ~障害通知、傾向分析、可視化による省力運用 (Software Design plus)

Windows Server 2016 にSNMPサービスをインストールする(英語版)

zabbix 3.0でWindows Server 2016 SNMPサービスを入れる方法をご紹介します。

環境

以下のAWS環境標準のWindows Server 2016のAMIを利用。

Microsoft Windows Server 2016 Base - ami-4325fa25
Microsoft Windows 2016 Datacenter edition. [English]

手順

Windows Serverの準備

SNMPサービスをインストールする

左下のWindowsマークのスタートメニューをクリックし、「Server Manager」を選択します。

「Dashboard」から「Add role and featrures」を選択します。

「Next」を選択します。

そのまま「Next」を選択します。

ここもそのまま「Next」を選択します。

ここでも「Next」を選択します。

中盤までスクロールして「SNMP Service」にチェックをいれます。

するとウインドウが開くので、「Add Features」を選択します。

「Next」を選択します。

「Install」を選択します。

「Close」で閉じます。
以上でSNMPサービスのインストールは完了です。

SNMPサービスの設定

「Server Manager」の右上の「Tools」をクリックし、「Services」を選択します。

一覧の中から「SNMP Service」を探して、右クリックで「Properties」を選択します。

「Secrurity」タブを選択し、「Accept community names」の「Add」ボタンを押下します。

「Community rights」を「READ ONLY」にし、「Community Name」になにか任意の名前を入力します。
入力したら「Add」を選択します。

「Accept SNMP packets from any host」をのラジオボタンをONにします。
そして「OK」を押せばSNMPの設定は完了です！

まとめ

以上でWindows Server 2016(英語版)へのSMPサービスのインストールすることができました。

SNMPをつかってZabbixなどの監視装置と連携することも可能です。
それらについてはまた別記事でご紹介しようと思います。

ひと目でわかる Windows Server 2016

Windows Server 2016 で拡張ネットワーキングをONにする【AWS】

AWS上のWindows Server 2016で拡張ネットワーキングをONにして見たいと思います。

そもそも拡張ネットワーキングとは？

拡張ネットワーキングは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。

Linux の拡張ネットワーキング - Amazon Elastic Compute Cloud

ということです。
つまり有効にするだけで通信が早くなるというすぐれものです。

拡張ネットワーキングを有効にする手順

環境

• Windows Server 2016 Base
• m4.large

Intelネットワークドライバをインストールする

以下のURLからIntelネットワークアダプタドライバーをダウンロードします。

downloadcenter.intel.com

「ProWinx64.exe」というファイルがダウンロードされたかと思います。
それを「ProWinx64.zip」に拡張子を変更します。

「ProWinx64.zip」を展開します。

コマンドプロンプトを開き、「ProWinx64.zip」を展開したフォルダに移動して以下のコマンドを実行してINFファイルを追加/インストールします。

pnputil -i -a PROXGB\Winx64\NDIS65\vxn65x64.inf 

Windows Server をシャットダウンします。

拡張ネットワーキングを有効にする

ローカルのPCなどの別の環境でいかのコマンドを実行して拡張ネットワーキングを有効にします。
Trueと応答されればOKです。

AWSCLIの場合

aws ec2 modify-instance-attribute --instance-id  i-xxxxxxxxxxxxxxxx --sriov-net-support simple

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxx -SriovNetSupport "simple"

拡張ネットワーキングが有効か確認する

デバイスマネージャーを開き、「ネットワークアダプター」の下に「Intel(R) 82599 Virtual Function」があることを確認します。

インスタンスに拡張ネットワーキングの属性が設定されている確認します。
"Value": "simple"となっていればOKです。

AWSCLIの場合

 aws ec2 describe-instance-attribute --instance-id i-xxxxxxxxxxxxxxxx --attribute sriovNetSupport --query 'SriovNetSupport'

PowerShellの場合

Edit-EC2InstanceAttribute -InstanceId i-xxxxxxxxxxxxxxxx -SriovNetSupport "simple"

上記2つがOKであれば拡張ネットワーキングは有効化されています。

まとめ

有効にするだけで通信がはやくなるのでどんどん設定していきましょう！

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWSのキー管理を比較してみた【KMS/CloudHSM】

AWSで利用できるキー管理のそれぞれの利点についてまとめてみました。

KMS

キーの保存場所/制御方法

• AWSにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 定義ポリシーをAWSが実行してキーの仕様を制御する
• AWSが責任をもって実行する

料金

• キー単位と使用量単位で料金がかかる

CloudHSM

キーの保存場所/制御方法

• AWS内で実行されるHSMにキーが保存される
• AWSのサービスや、その環境で動作するアプリケーションでキーが利用できる

キーの管理

• 自作のコードまたはSafenet APIでキーを管理することができる
• 自分たちで責任を持って管理する

料金

• 1時間あたりの課金
• CloudHSM Classicを利用する場合は前払い料金が発生する

3rdparty製ツール(AWS MarketPlace)

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• 1時間あたりの課金または1年単位での支払い

自作ツールでの管理

キーの保存場所/制御方法

• ツールによる(ローカル環境でもAWS内でも)
• EC2インスタンスでキーが利用できる

キーの管理

• ツール(ベンダー)による

料金

• ツール(ベンダー)による(場合によっては安くすむかも)

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

VGWのパス決定の優先順位まとめ

VGWの外のトラフィックのパスに複数のオプションがある場合は、以下のようにパスが特定されます。

パス決定の優先順位

1→2→3→4の順にパスが特定されます。

1. 範囲の狭いIPアドレスプレフィックス
   172.24.0.0/16より172.24.1.0/24より172.24.1.1が優先される
2. 静的ルートを使用したVPN接続
3. Direct Connectのパス
4. AS_PATHを利用した動的(BGP)ルートを使用したVPN接続

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

AWS Well-Architected Framework 5つの柱まとめ

AWS Well-Architected Framework 5つの柱について自分なりにまとめてみました。

セキュリティ

• すべてのレイヤーをセキュリティで保護する。
• リソースの変更やインスタンス内部へのログインなどログを記録する。
• セキュリティの確保を自動化させる。

信頼性

• 障害からの復旧、回復が迅速にできるようにする。
• 障害からの復旧を自動化する。
• 可用性を向上するため適切にスケーリングを設定する。
• 長年の勘とかに頼らない。

パフォーマンス効率

• 最新の技術を導入してその恩恵をうける。
• 分単位でデプロイを行う。
• サーバレスアーキテクチャを利用する。
• 適切な技術を導入する。

コストの最適化

• 不必要なコストを排除する。
• データセンターへの投資をやめる。
• 支出を分析する。
• マネージドサービスを利用して使用量を抑える。

運用上の優秀性

• コードで運用作業を実施する。
• 変更処理を自動化する。
• 想定外の障害などに対応するためのテストを行う。
• 手順は常に最新に保つ。

参考資料

https://aws.amazon.com/jp/architecture/well-architected/ http://media.amazonwebservices.com/jp/wp/Well-Architected_Whitepaper_v2_JP.pdf

AWSエキスパート養成読本[Amazon Web Servicesに最適化されたアーキテクチャを手に入れる! ] (Software Design plus)

AWSの設計におけるベストプラクティス

AWSでの設定におけるベストプラクティスみたいなものを自分なりにまとめてみました。

スケーラビリティを確保する

• インフラをシームレスにスケールできることがAWSの利点。
• AWSのすべてのレイヤーでスケーラビリティを活用するべき。
• 理想的なシステムはスケールアウトするだけでなく、不要なインスタンスが稼働し続けないようにシステムをスケールダウンするようなシステム。

インフラ環境を自動化する

• リソースのプロビジョニング、終了、設定は可能な限り自動化する。
• 例えば異常のあるリソースの検出と代替リソースの起動を自動化する。
• リソースの変更時に通知を受信するようにする。

リソースを使い捨てにする

• 各インスタンスの設定を同一にし、リソースのデプロイを自動化する。
• 使用していないリソースは削除する。
• 固定IPアドレスはできるだけ利用せず、新しいIPアドレスに自動的に切り替える。
• 古いインスタンスと新しいインスタンスをかんたんに置き換えられるようにしておく。

疎結合化する

• 独立したサービスでアーキテクチャを設計する。
• システムのレイヤー間にAWSのマネージドサービスを活用して疎結合化させる。
• ELBとSQSを利用するとかんたんに疎結合に近づくことができる。

AWSのサービスを最大限利用して設計する

• すべてをEC2インスタンスのサーバの内部で実施するのではなく、AWSサービスを利用することを検討する。
• マネージドサービスを利用してサーバレス化させる。

データの特性にあったデータベースを選択する

• 要件にあったデータベースを適切に選んで利用する。
• Read/Writeやストレージのサイズ、レイテンシーなどを考慮する。
• データベースにあわせて業務を決めるのではなく、業務をもとにデータベースを洗濯する。

SPOFをなくす

• 一箇所の障害によってシステム全体が停止するのを避けるため、冗長性を保たせる。
• 物理ハードが故障した場合でもサービスを維持し続けられるように設計する。

コスト効率をあげる

• コストを最適化する。
• リソースのサイズやタイプが適切かどうか確認する。
• 使用されていないリソースを終了する。
• マネージドサービスを積極的に利用し、利用料を下げる。

キャッシュを利用して通信料を抑える

• CloudFrontなどのキャッシュサービスを利用する。
• キャッシュを利用することで通信コストやレイテンシーなどを軽減することができる。

セキュリティを確保する

• ユーザには権限は利用する最小の権限しか与えない。
• データのやり取りは暗号化する。
• アクセスログを記録する。

参考資料

AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス-

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

EC2Schedulerをつかってみる

今回はEC2SchedulerというAWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールを利用してみたいと思います。

EC2Schedulerとは?

AWS公式が提供しているEC2インスタンスの起動停止をスケジューリングできるツールです。
EC2に起動停止の時間などを記載したタグをつけることで、インスタンスを毎日自動的に起動/停止してくれます。

EC2Schedulerをつかってみる

実際にEC2Schedulerを使ってみたいと思います。

CloudFormationテンプレートのダウンロード

以下からec2-scheduler.templateをダウンロードします。

docs.aws.amazon.com

CloudFormationスタックをつくる

マネジメントコンソールのCloudFormationから「スタックの作成」を選択します。

「テンプレートの選択」でさきほどダウンロードしてきたec2-scheduler-.templateを選択します。
選択したら「次へ」すすみます。

「スタックの名前」に任意の名前をつけます。
「パラメータ」はデフォルトのままいったん「次へ」でかまいません。

オプションも一旦そのまま「次へ」でかまいません。

CAPABILITYの「AWS CloudFormationによってIAMリソースが作成される場合があることを承認します」にチェックをいれ、「作成」を選択します。

スタックが作成されるのでしばらく待ちます。
「状況」が「CREATE_COMPLETE」となったら完了です。

インスタンスにEC2Schedulerのタグをつける

EC2Schedulerでスケジュール起動停止したいインスタンスを選択し、タグを設定します。
設定するタグの例は以下の表に示します。
時間はUTCでしか記載できないので注意が必要です。

EC2Schedulerのタグの例

タグ値の例	説明
0800;1800;utc;all	インスタンスは08:00に開始し、18:00にすべての曜日に停止します。
1000;1700;utc;weekdays	インスタンスは1000から開始し、月曜日から金曜日の17:00に停止します。
1030;1700;utc;mon,tue,fri	インスタンスは1030に開始し、月曜日、火曜日、金曜日にのみ17:00に停止します。
0815;1745;utc;wed,thu	インスタンスは0815に開始し、水曜日と木曜日のみ1745に停止します。
none;1800;utc;weekdays	インスタンスは、月曜日から金曜日の18:00に停止します。インスタンスは手動で起動する必要があります。
0800;none;utc;weekdays	インスタンスは月曜日から金曜日の08:00に開始します。インスタンスを手動で停止する必要があります。
none;none;utc;weekdays	インスタンスは手動で開始および停止する必要があります（自動アクションは実行されません）。
0800	インスタンスは08:00に開始され、Amazon DynamoDBテーブルに格納されているデフォルトのアクティブ日にデフォルトの停止で停止します。
0800;1800	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
0800;1800;utc	インスタンスは、Amazon DynamoDBテーブルに格納されているデフォルトの有効日数で、08:00に開始し、18:00に停止します。
default	インスタンスは、デフォルトのスケジュールで開始および停止します。
True	インスタンスは、デフォルトのスケジュールで開始および停止します。
EMPTY	インスタンスに対して実行されるアクションはありません。
Random String	インスタンスに対して実行されるアクションはありません。

以下公式ドキュメントから抜粋
Automated Deployment - EC2 Scheduler on AWS

EC2Schedulerが実行されたか確認する

マネジメントコンソールの「CloudWatch」から「メトリクス」、「EC2Scheduler」と選択します。

「Region」を選択します。

するとEC2Schedulerを設定したインスタンスのリソースIDを設定したが表示されるので、EC2Schedulerの実行状態を確認したいインスタンスのリソースIDを選択します。

グラフが0か1になっているのがわかるかと思います。
0が停止で1が起動です。
今回は1405;1420;utc;weekdaysと設定してみましたので設定通り14:05起動(1)、14:20に停止(0)されていることがわかります。

まとめ

EC2Schedulerをつかってインスタンスの自動起動停止を実施してみました。
夜間はインスタンスを停止するなど、コスト削減の基本ですのでこういったものを利用してみるのもいいかもしれません。

実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~

ALBでターゲットが全てunhealthyとなったときの動き

ALBでの動作

ALBでは対象のターゲットがヘルスチェックでunhealthyとなっても通信がターゲットに対して行われます。
そして、ALBでは正常なターゲットが含まれているAZがない場合、すべてのターゲットにリクエストをルーティングします。

おそらくフェイルオープンのような思想で設計されているのだと思います。

なにか障害が発生した際に全面断にするような運用をしたい場合には、セキュリティグループで拒否したり、待受ポート番号を変更したりなど、バックエンドインスタンス側に手を入れる必要があるかと思います。

参考:CLBでの動作

CLBの場合はヘルスチェックに失敗したインスタンスにリクエストをルーティングは行われない仕様で、動作に違いがありますので注意が必要です。

ですので全面断をかんたんに実装したい場合にはCLBのほうが適しているかもしれません。

Amazon Web Services　定番業務システム12パターン設計ガイド

Route53でTTLに0を設定したときの動作

Route53のTTLの設定は0から2147483647の間で設定することができます。

0を設定した場合は以下のような動作になります。

Route53でTTLに0を設定したときの動作

キャッシュせずに毎回、名前解決が実行されます。
そして、Route53からはTTL:0のレコードが返却されます。

(ただし、TTLに従って名前解決を行うかはクライアントやDNSキャッシュサーバの設定などに依存します。)

一般的にレコードをキャッシュさせたくない場合にはTTLに0などの短い値を設定するのが有効です。

参考

Nginxでのデフォルトの設定ではTTLにかかわらず名前解決を起動後の1回のみしか実施しない仕様になっています。

papix.hatenablog.com

Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版

旧バージョンのAmazonLinuxを利用する

マネジメントコンソール上からでは最新版Amazon Linuxしか選択することができません。

基本的には最新版の利用でかまいませんが、現行環境と環境を統一したいときなど、古いバージョンのAmazon Linuxを利用したいときがあるかと思います。

今回は最新ではないAmazon Linuxを入手する方法をご紹介します。

手順

EC2インスタンスの作成時に、コミュニティAMIを選択します。

そして検索で「Amazon Linux 2016」のように過去のバージョンを検索すると、該当のバージョンが出てきますのでそのAMIを利用してインスタンスを作成します。

ただ、コミュニティAMIは公式以外の第三者もAMIを公開しています。
公式のものが利用したい！という場合には以下のAWS CLIを実行し、amazonと表示されれば公式のものです。

aws ec2 describe-images --image-ids ami-xxxxxxxx --region ap-northeast-1 --query 'Images[].ImageOwnerAlias'

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

AWSCLIでS3全体を暗号化する

AWSCLIのaws s3 cpコマンドではオプションで--sseを指定することでAES256で暗号化することが可能です。

この際にコピー元とコピー先に同一のパスを指定することでパスを変えずに、オブジェクトを暗号化することが可能です。
具体的には以下のようにコマンドを実行します。

 aws s3 cp s3://kabegiwa-bucket/ s3://kabegiwa-bucket/ --recursive --sse

コピー元とコピー先にバケットを指定し、--recursiveで再帰的に--sseで暗号化しています。

また、このコマンドをcronなどに設定することで定期的にバケット全体を暗号化することが可能です。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-