Mais conteúdo relacionado Semelhante a マイクロサービスの基盤として注目の「NGINX」最新情報 ｜ 20180127 OSC2018 OSAKA (20) 2. 会社概要
2
社名 サイオステクノロジー株式会社
本社 東京都港区南麻布2-12-3 サイオスビル
営業所 関西、中部、九州
設立 1997年5月23日
資本金 1,481百万円
代表 代表取締役社長 喜多 伸夫
持株会社 サイオス株式会社
グループ
会社
SIOS Technology, Corp. （米国）
株式会社グルージェント
赛欧思（北京）科技有限公司（中国）
株式会社関心空間
Glabio, Inc.（米国）
株式会社キーポート・ソリューションズ
Profit Cube Inc.
9. Webサーバー マーケットポジション
©SIOS Technology, Inc. 9
出典：https://w3techs.com/technologies/comparison/ws-apache,ws-microsoftiis,ws-nginx
NGINXは Used by many sites、
Used by high traffic sitesの
カテゴリに分類
Apacheは Used by many sites、
Used by low traffic sitesの
カテゴリに分類
12. デジタル戦略への変更による成長例
©SIOS Technology, Inc. 12
出典:nginx.conf 2017: Keynote with Gus Robertson: https://www.nginx.com/blog/nginx-conf-2017-keynote-with-gus-robertson/
全店舗の16%を閉鎖し、eコマースとデジタル戦略にリ
ダイレクトすることで成長。
13. 独自サービスの作成による成功例
©SIOS Technology, Inc. 13
出典:nginx.conf 2017: Keynote with Gus Robertson: https://www.nginx.com/blog/nginx-conf-2017-keynote-with-gus-robertson/
MLBがインターネットを使用して野球の試合の配信を消
費者に提供したいため、自らサービスを作成
16. 【参考】Mode別の傾向
©SIOS Technology, Inc. 16
Mode1 属性 Mode2
SoR（System of Record） 目的、特性 SoE（System of Engagement）
信頼性、費用
重要視される
ポイント
敏捷性、柔軟性
堅牢性、コスト、パフォーマンス 要件 ブランドの収益、ユーザー体験
計画主導型、承認ベース ガバナンス 実証的、継続的、プロセスベース
エンタープライズサプライヤ 供給者
小規模、革新的なベンダ、
一部先進のエンタープライズサプライヤ
従来型のプロセスとプロジェクトを
計画的に実行する人材、
既存の仕組みをよく理解している人材
求められる
タレント
過去に実績がない最新型、チャレンジング
なプロジェクトを推進出来る人材、
最新の技術に明るく吸収力の高い人材
仕様やシステムありき、
大部分をメーカーやSIerに請負契約で依頼
文化
顧客主導型でビジネスやブランドの収益を
追求
数ヶ月～数年 期間 日/週単位
ベアメタル、
仮想化基盤（VMware、KVM）
基盤
Public/Private Cloud、コンテナ型
OpenStack、Docker…等
19. NGINXの特徴
A
A
A
1 Process = 1 Client 1 Process = 10000+ Clients
Apache NGINX
高速
軽量
高機能
NGINXは高速処理を実現するイベントループ方式を採用
©SIOS Technology, Inc. 19
21. 2つのソースコードブランチ
©SIOS Technology, Inc. 21
偶数バージョン（1.12）：安定版ブランチ
このブランチは、重大な問題やセキュリティの脆弱性を修正する必要があ
るときにのみ更新されます。Red Hat提供パッケージはこちらを採用
奇数バージョン（1.13）：メインラインのブランチ
このブランチは積極的に開発されます。新しいマイナーリリースは
（1.13.1、1.13.2等）を定期的に新しい機能や拡張機能を導入し、約4～
6週ごとに作られています。
安定版ブランチは重大な問題で
ないと修正されないため、開発
者はMaillineの利用を推奨し
ています。
NGINX Plusはmainlineより
forkして作成されます。
25. プロセスベースとイベントベース
1プロセス = 1クライアント
各プロセスは10-100 MBのメモリ領域を消費
Memory/CPUへの要求が多い
同期処理、排他制御
A
A
A
1プロセス = 10000クライアント以上
要求に応じたメモリ割り当て
効率よいMemory/CPUの利用
非同期処理/排他制御なし
1
2
3
4
標準ではプロセスIDは32767までのため、
クライアントが1万台を超えるとプロセス数
の限界やコンテキストスイッチのオーバー
ヘッドが大きくなり、本来の処理ができな
い状態が発生する
1つのプロセスにて、イベント毎に処理を行い、
終了したら次のイベントを実行する。
26. モダンなWebアーキテクチャへの改変へ
Load Balancer Web tier Application tier Database
Legacy approach
• 異なる機能を連結する
ソリューション
• スケールアウトが困難
• 複数のボトルネック
• 障害耐性の低さ
• 高いレイテンシー
• 運用が複雑
Modern approach
• 柔軟な構成
• 高いスケーラビリティ
• ローレイテンシー
• 簡単な運用
©SIOS Technology, Inc. 26
マイクロサービスアーキテク
チャとして注目を集める
32. 【参考】製品マトリックス
CORE FEATURES NGINX PLUS NGINX OPEN SOURCE
HTTP origin server ○ ○
Massively-scalable event-driven architecture ○ ○
Reverse proxy for HTTP, TCP, and mail (IMAP, POP3, SMTP) ○ ○
Application acceleration with HTTP keepalive offload,
caching, and compression
○ ○
HTTP/2, SPDY and SSL termination ○ ○
Authentication and bandwidth management ○ ○
LOAD BALANCING AND APPLICATION DELIVERY
Content switching and request routing ○ ○
Advanced HTTP and TCP load balancing ○
Session persistence ○
Advanced cache control ○
Application health checks ○
MEDIA DELIVERY
High-performance streaming for MP4/FLV media ○ ○
HTTP live streaming (HLS/VOD) ○
HTTP dynamic streaming (HDS/VOD) ○
Bandwidth management for MP4 media ○
RTMP media streaming ○
©SIOS Technology, Inc. 32
33. 【参考】製品マトリックス
ADMINISTRATION NGINX PLUS NGINX OPEN SOURCE
Graceful re-configuration and live binary updates ○ ○
Remote logging with syslog ○ ○
Live activity monitoring ○
On-the-fly load-balancing configuration ○
SUPPORT AND SERVICES
Community support ○ ○
NGINX support ○
Access to NGINX engineering for advice and guidance ○
Email and web support ○
Unlimited support incidents ○
Support hours 平日9:00 - 17:00
Pricing per instance
Software availability
Private repository
at nginx.com
Supported Platforms
Linux (RHEL/CentOS, Debian, SLES, Ubuntu), FreeBSD
10
Support (standard) from NGINX, Inc. 400,000円/年
©SIOS Technology, Inc. 33
37. NGINXのインストール
Yum コマンドよりインストールを実施、
インストール完了後、下記コマンドを実施します。
©SIOS Technology, Inc. 37
# yum install nginx
# systemctl enable nginx
# systemctl start nginx
# firewall-cmd --zone=public --add-port=80/tcp –permanent
# firewall-cmd –reload
下記コマンドにて動作確認が行なえます。
$ nginx -v
nginx version: nginx/1.13.3
$ ps -ef | grep nginx
root 1088 1 0 19:59 ? 00:00:00 nginx: master process …
nginx 1092 1088 0 19:59 ? 00:00:00 nginx: worker process
39. Dockerの特徴をおさらい
©SIOS Technology, Inc. 39
項目 概要
リソース リソース使用量、オーバーヘッドが非常に少ない
用途 大量にサーバーを並べる必要があるシステムでの利用が
中心
使い捨ての概念でアップデート時にはコンテナごと入れ
替える手法を取る
可搬性 同じDocker Engineが動いている環境であれば、環境は
選ばない、Linux環境をWindows環境に持ち込むことは
基本不可
43. NGINXの設定：SSL設定
©SIOS Technology, Inc. 43
server {
listen 80 default_server;
server_name www.example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2 default_server;
server_name www.example.com;
ssl_certificate cert.crt
ssl_certificate_key cert.key
ssl_ciphers HIGH;
}
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
すべてのトラフィックに暗号化を適用することが可能
44. NGINXの設定：リバースプロキシ設定
©SIOS Technology, Inc. 44
server {
listen 80 default_server;
location ~ [^/].php(/|$) {
fastcgi_split_path_info ^(.+?.php)(/.*)$;
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/var/run/php7.0-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
}
PHPアプリケーションのリクエストを振り分けることが可能
PHP FPMは別途導入が必要です。
45. NGINXの設定：ロードバランシング
©SIOS Technology, Inc. 45
http {
upstream my_upstream {
server server1.example.com;
server server2.example.com;
least_conn;
}
server {
listen 80;
location / {
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
}
デフォルトのロードバランシングアルゴリズムはRound Robinです。
•least_connは、アクティブ接続数が最も少ないサーバを選択します。
•デフォルトでは、NGINXは、プロキシされたサーバーの名前とポー
トにホストヘッダーを書き換えます
•proxy_set_headerは、元のクライアントのホストヘッダーをオー
バーライドし、パスします。
46. NGINXの設定：キャッシュ
©SIOS Technology, Inc. 46
proxy_cache_path /path/to/cache levels=1:2
keys_zone=my_cache:10m max_size=10g
inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
#proxy_cache_valid 5m;
proxy_set_header Host $host;
proxy_pass http://my_upstream;
}
}
proxy_cache_pathは、ディスクのレイアウト、サイズと場所、およ
びキャッシュの他のパラメータを定義します
proxy_cacheは、このコンテキストのキャッシングを有効にします。
proxy_cache_validは、上流でCache-Controlヘッダーが返されない
場合に有効です。
47. Apacheの設定ファイルを比べてみると
Listen 80
ServerRoot "/etc/httpd"
DocumentRoot "/var/www/html/"
User nobody
Group nobody
<IfModule prefork.c>
MaxClients 150
StartServers 5
MinSpareServers 5
MaxSpareServers 15
</IfModule>
©SIOS Technology, Inc. 47
server {
listen 80 default_server;
server_name www.example.com;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
NGINX
Apache
51. 実事例: Apacheフロントとして性能向上
既存のApache HTTP Serverの前に配置することで、
リバースプロキシおよびコンテンツキャッシュに利用し、
パフォーマンスを向上
現状のアプリケーションに手を入れることなしに、スケーラブルな環
境を提供
リーバスプロキシー
キャッシュ
NGINX Apache アプリケーション
サーバー
データベース
Apache/アプリケーションサーバー/データベースには手を入れないNGINXサーバーを配置
©SIOS Technology, Inc. 51
56. Providing tools that reduce the complexity of
managing distributed apps
アプリケーション、特にコンテナや仮想マシンに分散し
て実行されているアプリケーションの管理の複雑さを軽
減するツールを提供します。
これらのレガシーアプリケーションを最新のアプリケー
ションアーキテクチャに移行させるツールを提供します。
10人のユーザー、1,000万人のユーザー、1億人以上の
ユーザーなど、アプリケーションの規模を拡大するツー
ルを提供します。
私たちは、拡張可能なアプリケーションを構築するのを
手伝っていきます。私たちはこれらのアプリケーション
にインテリジェンスをもたらすつもりです。
SIOS Technology, Inc. 56
Notas do Editor OSSがオープンイノベーションの領域で使われるようになってきている。
↓
SIOS is Innovative Open Solution→Innovative Solution 事業企画
2016年3月
Apache 48.1％ →83％
NGINX 33.2％ →129％
IISの減少もあり、NGINXの立ち位置は明確になりつつあります。 PayPal傘下として米国で急成長中のサービスで、「P2P」の金融サービス、いわゆる「個人間送金」の仕組みを提供しており、特に若者の間で大人気となっている
結果、彼らは巨額の採用をしており、業界全体を混乱させることができました。 しかし、伝統的な銀行はそれを簡単に取っていません。
そのような中で米国のウェルズ・ファーゴ(英:Wells Fargo & Co.)は、カリフォルニア州サンフランシスコに本社を置き、西部を地盤とする、2017年7月現在アメリカ合衆国で最も支店数が多い金融機関であるWells FargoはZelleと呼ばれる独自のアプリケーションをすでに発表しています。
日本でもKyash、paymo、LINE Payなどの個人間送金アプリが普及してくれたおかげで、今までいろいろと面倒だった飲み会の割り勘がアプリで簡単にできるようになりました。 素晴らしい例はMacy'sです。あなたがメイシーズを見ると、彼らはすでに過去3年間で全店舗の16％を閉鎖しています。何が行われたのかは、彼らが電子商取引とデジタル戦略にリダイレクトすることができた5億5,000万ドルの現金で解放されています。
彼らは、2億5,000万ドルを追加し、デジタル戦略にリダイレクトするために8億ドルを払い、電子商取引を行い、デジタル体験を店舗に持ち、維持したいと考えています。これはリダイレクトです。あなたのリソースをデジタル変換にリダイレクトします。
ここで使用する例はメジャーリーグです。
MLBは、インターネットを使って、自分の野球のゲームを「トップに」流すことを消費者に直接求めたかったのです。彼らは自分のサービスを作りました。
そして、他の企業も、HBO、ワールドレスリングエンタテインメント、ESPNなどの企業、サービスの構築についての助けを得るために、彼らに近づくほど成功しました。それは彼らが独立した企業として会社をスピンアウトし、新しい投資家を引き付けたことで大成功でした。
もともと、ディズニーが入って33％のシェアを10億ドルで買った。 最近では、75％のシェアを獲得するために15億ドルの追加投資を実施しています。
それを今見れば、その独立した企業は30億ドル以上の価値があります。
そしてMLBの一員である30の野球チームが何を表しているのかを見ると、野球チームごとにMLB内で作成した別の企業から得た収益で野球チーム1チームあたり8500万ドルを超えています。
そして、彼らはBAMTechという会社の15％の所有権を維持しています。 当時は、ロシアのRamblerというポータルサイト事業者でシステム管理者をしていた。あるとき開発者から、proxyを使っても2台目のApacheがアクセラレートされないと相談を受け、調べてみたらproxyモジュールの機能が弱いことがわかった。そこでproxyやキャッシュを改善してアクセラレータとして正しく動くようにしていった
NGINXの由来はエンジンという言葉を使いたかったから。
Nginxという名称は、「エンジン」という言葉の響きの良さに、Linux/Unixなどの「X」を組み合わせて決めたものだという。「名前を決めるまでに1年ほどかかった。"ダイナミック"という言葉も好きで、候補の1つになっていた。製品のなかでもっとも時間をかけたのが命名プロセスかもしれない(笑)」 LinuxなどUNIX系のOSでは、メモリ上で実行中のプログラムに与えられるプロセス番号は符号付き16ビット整数だ。つまり、デーモン（サーバプロ セス）も含め、すべての実行中のプロセスには1～32767までのユニークな番号が与えられていることになる。ところが、HTTPサーバのApacheな どはクライアント1台からのリクエストに対して1つのプロセスを生成するため、必然的に同時接続数は3万クライアント程度が上限となる。 http://www.oracle.co.jp/customers/CustomerCaseStudy_NTTdocomo_WLS_JA.pdf クラウド時代のアプリケーションは、サービスを提供するコンポーネントのような小さなソフトウェアが多数連係する、いわゆる「マイクロサービス」と呼ばれるアーキテクチャを備えたものになると考えられています。
このマイクロサービスアーキテクチャを備えたアプリケーションの内部では、各サービス間をつなぐためのネットワークがまるで網の目のように張り巡らせられ、そこでさまざまなトラフィックが発生していきます。
そしてこのネットワークを安定的かつ効率的でセキュアに運用することはマイクロサービスの運用に欠かせない基盤であり、そのためにはトラフィックのルーティングルールの設定、トラフィックが偏らないようにロードバランスの実現、セキュリティのための暗号化通信や認証サービス、ポリシーの設定、そして全体のモニタリングなど、さまざまなネットワークのサービス機能が求められます。
server defines the context for a virtual server
listen specifies IP address/port that NGINX listens on; if no IP address (as here), NGINX binds to all IP addresses on system default_server specifies to use this server if hostname is not known
server_name specifies hostname of virtual server HPPT2にはいち早く対応
SSLターミネーションとして利用するケースもあり Requires PHP FPM:
apt-get install –y php7.0-fpm
Can also use PHP 5
Similar directives available for SCGI
and uwsgi
Additional PHP FPM configuration may
be required 参考：https://www.nginx.com/products/nginx/load-balancing/
Default load balancing algorithm is Round Robin
• least_conn selects server with fewest active connections
• By default NGINX rewrites Host header to name and port of proxied server
• proxy_set_header overrides and passes through original client Host header
• least_time factors in connection count and server response time (available in NGINX Plus only)
参考：https://www.nginx.com/blog/nginx-caching-guide/
レベルセット
/ path / to / cache /の下に2レベルのディレクトリ階層を作成します。 1つのディレクトリに多数のファイルを格納すると、ファイルへのアクセスが遅くなる可能性があるため、ほとんどの展開では2つのレベルのディレクトリ階層を推奨します。 levelsパラメータが含まれていない場合、NGINXはすべてのファイルを同じディレクトリに置きます。
keys_zone
キャッシュキーと、使用タイマなどのメタデータを格納するための共有メモリゾーンを設定します。キーをメモリにコピーすると、NGINXはディスクに移動することなくリクエストがHITかMISSかを素早く判断し、チェックを大幅に高速化できます。 1 MBのゾーンには約8,000のキーのデータを格納できるため、この例で構成された10 MBのゾーンでは約80,000のキーのデータを格納できます。
max_size
キャッシュのサイズの上限を設定します（この例では10ギガバイト）。オプションです。値を指定しないと、キャッシュが使用可能なすべてのディスク領域を使用できるようになります。キャッシュ・サイズが限界に達すると、キャッシュ・マネージャと呼ばれるプロセスは、最も最近使用されなかったファイルを除去して、キャッシュ・サイズを限界まで戻します。
非アクティブは、アイテムがアクセスされずにキャッシュに残る期間を指定します。この例では、60分要求されていないファイルは、期限切れであるかどうかにかかわらず、キャッシュマネージャプロセスによって自動的にキャッシュから削除されます。デフォルト値は10分（10m）です。非アクティブなコンテンツは期限切れのコンテンツとは異なります。 NGINXは、キャッシュコントロールヘッダー（Cache-Control：max-age = 120など）によって定義された期限切れのコンテンツを自動的に削除しません。有効期限が切れた（古い）コンテンツは、非アクティブで指定された時間アクセスされていない場合にのみ削除されます。期限切れのコンテンツにアクセスすると、NGINXはオリジンサーバからコンテンツをリフレッシュし、非アクティブタイマーをリセットします。
NGINXは最初にキャッシュ用のファイルを一時記憶域に書き込み、use_temp_path = offディレクティブはNGINXにキャッシュされるディレクトリと同じディレクトリに書き込むように指示します。ファイルシステム間で不必要にデータをコピーしないようにするには、このパラメータをoffに設定することをお勧めします。 use_temp_pathは、NGINXバージョン1.7.10およびNGINX Plus R6で導入されました。 分散アプリケーションの管理の複雑さを軽減するツールを提供する
