2018年 10月 の投稿一覧

Save the date! NGINXがRed Hat Forum Tokyo 、Japan Container Daysに登壇します!

もうお申込みはお済みでしょうか?

NGINXが、11/8(木) 開催のRed Hat Forum Tokyoではゴールドスポンサーとして、12/4(火)-5(水) 開催のJapan Container Daysではランチスポンサーとして、出展します!

いずれのイベントでも、NGINX社による講演と、展示ブースでの参加を予定しています。また、どちらのイベントでも、サイオステクノロジーがパートナーとして、共同でブース運営に参加します。

お申し込みは以下のサイトから。

 

 

ぜひ、皆さまのご来場をお待ちしております!

11/14(水)、NGINX MeetUp Tokyo #1 を開催します!

前回のMeetUp #0に続き、11/14(水)にNGINX MeetUp Tokyo #1 を開催します。

概要

日本のNGINXユーザー、また関心をお持ちの方に向けてNGINX最大のイベント NGINX .conf 2018 の最新情報とWeb Application Firewall機能のNGINX WAFをご紹介します。2つのセッションとセッション終了後には懇親会を用意しておりますので、NGINXを利用する方同士での交流もいただける場になっています。

これからNGINXを使ってみたいという方も、NGINXを使いこなしている方も、NGINXにご興味をお持ちの方、NGINXが大好きなかたまで皆様のご参加をお待ちしております。

なお、Meetupの内容は後日動画配信を予定しております。遠方の方は配信動画の公開をお待ち下さい。 NGINX MeetUp Japanのグループ登録も合わせてよろしくおねがいします!!

プログラム

  • 16:30~    受付

  • 17:00~17:10 オープニング & NGINX Meetup Japan 立ち上げについて

  • 17:10~17:40 講演1 NGINX .conf 2018最新情報

    概要:サイオステクノロジーの原尚史が、アトランタで2018年10月6日〜8日に開催されたNGINX .conf 2018 の最新情報をお伝えします。
    現地で入手したNGINXの最新情報をどこよりも早くお伝えいたします。 

    講師:サイオステクノロジー株式会社 イノベーティブソリューション事業企画部 原 尚史

  • 17:40~18:10 講演2 NGINX WAFについて

    概要:サイオステクノロジーのセキュリティエヴァンジェリスト 面 和毅が、NGINX WAFについてご紹介します。
    コミュニティ版とPlus製品の違いを含めてご紹介予定です。 

    講師:サイオステクノロジー株式会社 セキュリティエヴァンジェリスト 面 和毅

  • 18:10~19:00 懇親会 NGINX ノベリティ抽選会!!

※講演資料は本サイトにて後日公開予定です。

イベント参加について

以下URLよりお願い致します。

【申し込みURL】

https://nginx-mj.connpass.com/event/103617/

ソフトウェアロードバランサーによるアジャイル実現

こんにちは、サイオステクノロジーの原です。
今回は“アジャイル”をテーマに、いかにソフトウェアロードバランサーがアジャイルに向いているかについてブログに記載したいと思います。

アジャイルとは

アジャイルは従来のウォーターフォール手法(“要求仕様 – 設計 –  テスト – 実装 – 保守”といった各フェーズを順を追って着実に進めていく)と違い、
各フェーズ毎で順を追わず、柔軟に対応することで工数削減に繋がる手法です。

例えば、各データセンターへのロードバランサー導入プロジェクトがあるとします。

ウォーターフォール手法では、要求仕様フェーズでスケジュール、納期、成果物等をお客様としっかり合意を得た上で仕様書を作成し、仕様書に基づいて設計書に起こします。
設計書が完成するとロードバランサーのテストが始まり、各テスト項目がクリアした段階で実装に向かいます。
着実にフェーズをこなしていくため、正確性はありますが俊敏性は欠けています。

一方アジャイルでは、要求仕様フェーズである程度の情報が整い次第、実装に向けて各担当チームは各フェーズ(設計・テストフェーズ)に移行します。

このように各フェーズを一つずつ着実にこなしてから次フェーズに移行していく必要が無く、同時並行で各担当フェーズを進めていくことが出来ます。
また不足部分は各担当チームと柔軟に連携して改良していくことが出来るので、正確性に加えて俊敏性も実現出来る点が特徴です。

 

ソフトウェアロードバランサーでアジャイル実現

ハードウェアロードバランサーではスペックが固定されており、柔軟にスケールアウトかつスケールアップが行えず、高トラフィック時はネットワーク運用チームとの連携が必要となり、
設定変更時のトラフィックの影響範囲の調査や場合によってルール変更も必要です。そのため、設定変更の際も数時間から数日掛かるケースがあります。

しかし、ソフトウェアロードバランサーではハードウェアに依存しませんので、柔軟にスケールアウトかつスケールアップが行えるため、各チームが機敏に運用を行うことが可能となります。
またDevOpsで完結出来るため、ネットワーク運用チームとの連携は不要となり、運用者は設定変更を行う場合にも数秒で設定変更が行えます。

ソフトウェアロードバランサー としてのNGINX 

ソフトウェアロードバランサーの中でもNGINXはスケールアウト・スケールアップといったスケーラビリティに優れている以外にも、性能面でも優れています。
基盤も高スペックのものでなくても、パフォーマンスを発揮します。(2CPU core / 4GB RAMで90,000RPS 4,000 RSA SSL TPS  4,500 ECC SSL TPS 1GB スループットを実現)

ですので、トラフィック増加により無駄に運用変更を行う機会も無くなります。

下記詳細なサイジング・パフォーマンス例がございますのでご参考までに。

【サイジング・パフォーマンス例】
Sizing-Guide-for-Deploying-NGINX-on-Bare-Metal-Servers

またNGINX Plusではリアルタイムパフォーマンスモニター機能もGUIで搭載していますので、問題となっている点もすぐに解明出来、運用変更が可能です。

現在、ハードウェアロードバランサーを運用されている方は一度ソフトウェアロードバランサー NGINXを検討してみてはいかがでしょうか。
無料で評価版も30日間提供しておりますので、お気軽に下記ページからお問合せ下さい。

【評価版申請ページ】
https://nginx.sios.jp/free-trial

 

【参考URL】
https://www.nginx.com/blog/how-hardware-load-balancers-are-killing-agile-development-and-competitive-advantage/

nginx 1.15.4と1.15.5がリリースされました。

こんにちは、サイオステクノロジーの原です。

nginx.orgで2018年9月25日に1.15.4、2018年10月2日に1.15.5が公開されました。
今回のバージョンアップではSSL関連のディレクティブ機能拡充、ワーカープロセス・gRPC・error_pageディレクティブ関連のバグ修正が含まれています。

以下、リリース内容の詳細を参考訳として記載します。

nginx 1.15.4 リリース内容

<機能追加>
*)”ssl_early_data”ディレクティブでOpenSSLを使用可能。

<バグ修正>

*)ngx_http_uwsgi_moduleのバグ修正。Chris Caputoさん、ありがとう。

*)keepaliveディレクティブ文を使用すると、いくつかのgRPCバックエンドとの接続はキャッシュされない可能性があった。

*)”error_page”ディレクティブを使用して初期要求処理エラー(特にコード400のエラー)をリダイレクトすると、ソケットリークが発生することがあった

*)リクエストが “error_page”指示でリダイレクトされた場合、エラーを返すときに “return”ディレクティブ文は応答コードを変更しなかった。

*)標準エラーページとngx_http_autoindex_moduleモジュールの応答では、”bgcolor”属性が使用され、ブラウザでカスタムカラー設定を使用すると
   誤って表示されることがある。Nova DasSarmaさん、ありがとう。

<仕様変更>

*) “no suitable key share”および”no suitable signature algorithm”のSSLエラーのログレベルが「crit」から「info」に下げられました。

nginx 1.15.5 リリース内容

<バグ修正>

*)OpenSSL 1.1.0h以降を使用している場合、ワーカープロセスでセグメンテーションエラーが発生する可能性があった。バグは1.15.4でも発生していた。

*)潜在的なバグ修正。

 

【参考URL】

http://nginx.org/en/CHANGES

NGINX PlusのAPIゲートウェイソリューション

こんにちわ、サイオステクノロジーの原です。

今回はNGINX PlusのAPIゲートウェイ機能に焦点を当てたいと思います。

 

APIゲートウェイとは

Web APIを用いたクラウドインテグレーションを行なう為に必要となるアーキテクチャです。

企業ネットワーク内にデプロイされているアプリケーションとパブリッククラウドサービスとの間
にゲートウェイとして機能し、全ての通信はこのAPIゲートウェイを介して行ないます。

例えば、通常はクライアントからバックエンドの各マイクロサービスのAPIを数回に渡って
呼び出すことが必要であり、クライアント側で各マイクロサービスのAPIを管理する必要が
ありました。
このAPIゲートウェイを導入することにより、クライアントはAPIゲートウェイに対して1回だけ
APIを呼び出すだけで、後はAPIゲートウェイが各マイクロサービスのAPIの呼び出しを肩代わり
してくれます。

APIゲートウェイの使用例

下記の表はAPIゲートウェイとしてのNGINX Plusが外部ソースからのAPIリクエストを管理し、
内部サービスにルーティングするための要件を満たす方法を示しています。

  APIゲートウェイ要件 NGINX Plusソリューション
コアプロトコル REST(HTTPS)、gRPC HTTP、HTTPS、HTTP / 2、gRPC
その他のプロトコル TCP-borneメッセージキュー WebSocket、TCP、UDP
リクエストルーティング リクエストは、サービス(ホストヘッダー)、APIメソッド(HTTP URL)、およびパラメーターに基づいてルーティングされます ホストヘッダー、URL、およびその他の要求ヘッダーに基づいた非常に柔軟なリクエストルーティング
APIライフサイクルの
管理
従来のAPIリクエストの書き換え、廃止予定のAPIへの呼び出しの拒否 要求に直接ルーティングまたは応答するための包括的な要求書き換えと豊富な意思決定エンジン
脆弱なアプリケーションの保護 APIとメソッドによるレート制限 送信元アドレス、要求パラメータを含む複数の基準によるレート制限。バックエンドサービスへの接続制限
オフロード認証 着信要求の認証トークンの検査 JWT、APIキー、外部認証サービス、OpenID Connectなどの複数の認証方法のサポート
変化するアプリケーショントポロジの管理 構成変更を受け入れ、青緑のワークフローをサポートするためのさまざまなAPIの実装 エンドポイントを特定するためのAPIとサービスディスカバリーの統合 ブルーグリーンデプロイメントやその他のユースケース用にAPIを編成できます

NGINX PlusではWebトラフィックを容易に管理出来、プロトコル(HTTP/2, HTTP, FastCGI, uwsgi)を変換し、一貫した設定とモニタリングGUIの提供が可能です。

NGINX PlusのAPIゲートウェイ機能

NGINXコミュニティ版はもとはHTTP(Web)トラフィックのゲートウェイとして開発されており、設定されているプリミティブはHTTPリクエストの観点から表現されています。
NGINX Plusではより複雑なAPIをマップし、多くの一般的なAPIゲートウェイタスクを処理します。

NGINX PlusによるAPIゲートウェイの各処理方法の詳細については以下のリンクを参照下さい。

【参考URL】

https://www.nginx.com/blog/consolidating-your-api-gateway-and-load-balancer-with-nginx/