1. /
  2. takashima

takashima

Google Wifiについて

前回に引き続きWifiネタになってしまいますが、今回はGoogle Wifiについて書きたいと思います。
先日Google社がwifiルータを発表しました。
その名もGoogle Wifi（そのまんまですね・・・。）

一般的なWifiルータと同様の使い方はもちろん可能ですが、
現状普及している機器にはないさまざまな機能が搭載されています。

###802.11s ワイヤレスメッシュネットワークについて
前回の記事では出てこなかった規格になりますが、
そもそも802.11sとはなんぞや？というところを記述します。

端的にいいますと、複数のアクセスポイント（Wifiルータ）を設置し、メッシュ状に各アクセスポイント間を結ぶことで電波のカバー範囲を強化するという技術になります。
たとえば、広いオフィスのどこにいても同じアクセスポイント設定でLANへの接続が可能となります。

###Network Assist機能について
複数設置を行うことで快適なWifi環境を構築できることは前述のとおりですが、単体設置であっても最適化を行う機能が搭載されています。
それがNetwork Assist機能です。
Wifiルータの設定を行ったことがある人は見たことがあるかと思われますが、Wifiにはチャンネルという概念があり、規格ごとに複数のチャンネルが割り当てられています。
複数あるチャンネルの中から最適なチャンネルを自動で選択し、速度低下を防止する仕組みとしてこのNetwork Assist機能が搭載されているそうです。

###最後に
発表を見た限りですが、さすがGoogle社が出す製品で先鋭的！と感じました。
あとは気になる価格と発売日ですが、米国ではすでに予約が始まっており1台129ドル、3台セットで299ドルとのことです。
日本向けの展開が待ち遠しい限りです。

リンクバルはいろいろな技術を習得する機会に恵まれています。
今までの経験をベースにさらに新しいことにチャレンジしたい方、ぜひ応募お願いします。
採用情報はコチラ

無線LAN（Wi-Fi）の規格について

リンクバルでエンジニアをしている高島です。
スマホの普及とともに自宅にWi-Fiルータを導入された方も多くいらっしゃるかと思います。
弊社のオフィスにおいてもWi-Fiは利用されています。

このWi-Fiですが、LANケーブルを配線せずにデバイスをNWに接続できるため大変便利なものではありますが、対応規格が親機・子機間でマッチしている必要があったり、通信速度が違ったり、メリット・デメリットがあったりと意外と複雑です。

NW屋さんでないと一つ一つの規格を詳細に把握する必要はないかもしれませんが、IoTなんかが流行っている世の中ではありますので、ざっくり知っていても損はない・・・と思います。

###通信規格について
デバイスのカタログの対応規格欄を見るとIEEE802.11から始まる形式で記載されているかと思います。
IEEE802はIEEE標準規格のうちローカル・エリア・ネットワークなどに関する規格を定めたものになり、その中でもIEEE802.11はワイヤレスLANを対象としています。
ここまでは　ふーん・・・　と思っていただければよろしいかと思われます。

重要なのはその後ろに続く文字になります。

###規格の種別
前述しましたが、規格ごとに通信速度が異なったり、メリット・デメリットがあります。
ざっと普及している規格を表にしてみます。

規格 通信速度（規格上の最大値） 周波数帯域
11a 54Mbps 5GHz
11b 11Mbps 2.4GHz
11g 54Mbps 2.4GHz
11n 600Mbps 2.4GHzまたは5GHz
11ac 6.9Gbps 5GHz

###メリット・デメリットについて
普通に考えたら、下に行くほど速度が速いなら、下の方の規格を選べばいいじゃん　と考えますよね？
何もないだだっ広い部屋で利用するのであればその通りだと思います。
ただ自宅などの場合、なかなかそうはいきません・・・。

そこで先ほどの表にさりげなく記載した周波数帯域の話が出てきます。

####2.4GHz帯
■メリット
・古くから利用されている規格のため、対応機器が多い
・5GHzと比較すると電波が回りこみやすい性質（回折性）があるため、障害物が多い環境では5GHzより有効

■デメリット
・対応機器が多く帯域の利用率が高いため他の機器との電波干渉が発生しやすい
・電子レンジの電磁波も2.4GHz帯のためノイズとなる
　→環境によってはレンジを使うとネットの速度が遅くなったり、不安定になる　ということも。。。

####5GHz帯
■メリット
・対応機器が少なく帯域の利用率が低いため、2.4GHzよりも他の機器との電波干渉が発生しにくい
・LANケーブルによる有線接続よりも場合によっては速い
　　→11ac対応機器は規格上の通信最大速度が1Gbpsの物理LANを超えています。

■デメリット
・対応機器が2.4GHzに比べ少ない
・回折性が低く、障害物があると途端に速度が遅くなってしまったり、不安定になる場合がある

###総括
利用シチュエーションや環境に合わせて適切な規格を使うことで、安定性や高速な通信速度を確保することが可能となります。
自宅のWi-Fiルータを新調したいなどの機会がありましたら、ぜひご参考いただけますと幸いです。

###最後に
リンクバルはいろいろな技術を習得する機会に恵まれています。
今までの経験をベースにさらに新しいことにチャレンジしたい方、ぜひ応募お願いします。
採用情報はコチラ

現行世代と旧世代のインスタンス比較（性能&コスト）

リンクバルでエンジニアをしている高島です。

最近EC2上でApache Jmeterを利用しての負荷テストを実施していて、いろいろなインスタンスタイプ・サイズやOSで試したりしています。
AWSではインスタンスタイプごとに現行世代と旧世代の2種類のインスタンスが選べますが、現行世代の方がベースの物理マシンも新しいため性能がよかったりします。

ただ、マシン買い切りのオンプレミスとは異なり、時間単位でコストが掛かってくるAWSでは性能のよいインスタンスをとにかく投入するのではなくランニングコストも視野に入れて選定が必要となってきます。
そこで、新旧で性能およびコストの比率をチェックしてみたいとおもいます。

###性能測定実施

測定にはUnixBenchを利用してみました。
まずはインストールです。

実行に必要なパッケージを先に導入します。

[bash] # yum install perl-Time-HiRes
# yum install gcc
[/bash]

公式からソースコードをダウンロードし、展開します。

[bash] $ wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/byte-unixbench/UnixBench5.1.3.tgz
$ tar zxvf UnixBench5.1.3.tgz
$ cd UnixBench
[/bash]

実行するとコンパイルされた後に処理が開始されます。

[bash] $ ./Run
[/bash]

###比較対象
比較対象はvCPU数とメモリ容量をあわせたいので、c4.4xlargeとc3.4xlargeを選択しました。
ともにvCPU数が16、メモリ容量が30GiBになります。

###性能比較

c4.4xlarge c3.4xlarge c4/c3
1vCPUのスコア 1950.3 1793.7 約108%
16vCPUのスコア 8805.8 7753.3 約113%

物理CPUが（c4インスタンス）E5-2666 v3 @ 2.90GHzと（C3インスンタンス）E5-2680 v2 @ 2.80GHzのため、CPU世代が進んでいてクロック差もあるため妥当な差だと思います。
テストケースごとのスコアの掲載は省略していますが全体的にc4インスタンスが上回る結果となりました。

###コスト比較

c4.4xlarge c3.4xlarge c4/c3
$1.061/h $1.021/h 約104%

c4インスタンスの方が上ですが、ほとんど気にならないレベルです。

###総括
性能差に対して、コストの差が小さいため新しくインスタンスを選択する際には素直に現行世代インスタンスを選んだ方が無難だと思います。
ただし、新しくリリースされたインスタンスについてはリリース直後は物理サーバの絶対数が少ないためか、オートスケールなどで起動できる台数が制限に引っかかってしまうことがあるようで、大型システムではそのあたりについて考慮する必要がありそうです。

元オンプレ系インフラエンジニアから見たAWSについて

みなさん初めまして！リンクバルでエンジニアをしている高島です。

私は過去オンプレミスシステム(以降オンプレ)のインフラ部分の設計・構築・運用に携わってきましたが、リンクバルではパブリッククラウドの最大手Amazon Web Serviceを利用して各種サービスを運用しています。
オンプレとクラウドのメリ・デメ比較については多くの技術サイトで語りつくされていると思いますのでそちらにお任せし、ここでは元オンプレ系インフラエンジニアの目線から衝撃を受けた点を挙げていきたいと思います。

####(1)サーバ立ち上げまでのセットアップ時間が10分以内！！

AWSのコンソールからEC2の立ち上げを行うのに必要な時間は10分以内（！！）です。
これはずっとメディアからOSをインストールする環境で仕事をしてきた者としては驚異的でした。
オンプレでもVMWare、Hyper-Vなどの仮想化技術を利用し一度作成したイメージから2台目以降を複成することは可能ですがAWSでは用意されたAmazonマシンイメージ（以降AMI）を利用することで1台目から素早く立ち上げることが可能です。
また、このAMIはAmazon以外にも各社・各団体も提供しており無数に存在します。
これらを柔軟に利用することで非常にすばやくシステムの立ち上げが可能です。

####(2)HWをまったく意識せず構成が可能

AWSに限らず、クラウドコンピューティングでは物理的なHWが隠蔽され、利用者側は全く意識することなく必要なリソースを必要なだけ借りられるというメリットがあります。
オンプレでも複数のサーバHWを共有ストレージに繋ぎこみ、仮想化技術を持ちいてHW間のノード移動させることは可能ですが、オンプレはあくまで手元にあるHWの制約を受けるためクラウドに対し柔軟性が劣ります。
また、AWSでは作成したAMIやスナップショットを同一AZ内において自由に扱うことが可能です。
これはテープ装置やストレージ間レプリケーションを用いてバックアップ・復旧の運用設計をしてきた者としては非常に素晴らしい仕組みと感じました。

####(3)IOPSに対しての課金

AWSではストレージ、NW、ロードバランサなどで発生するIOPSに対して課金が発生します。
また、デフォルトの帯域に不満があればコストを掛けることで増強することが可能です。
オンプレでDBサーバやバッチサーバのIOPS周りの速度に頭を悩まされてきた者としてはこの仕組みは衝撃的でした。
コストを掛けただけ性能が上げられる仕組みのため、柔軟性が非常に高いと思います。
ただし、オンプレのように手元にある機器を好きなだけ使えるわけではなく、使った分がコストになるため思考の転換が必要となります。

まだまた語りつくせないところではありますが、今回はここまでとさせていただきます。
ここまで読んでいただきありがとうございました！

リンクバルではクラウドの経験が浅い人でもさまざまな経験を経ることでスキル習得が可能です。
オンプレミス環境が恋しい気持ちもありつつ(笑)も、クラウドコンピューティングの成長性はとてもよい技術的刺激になると考えています。
AWSの経験を積みたい方、是非ともリンクバルへよろしくお願いします！！

© Copyright 2024 LINKBAL Blog. All rights reserved.