まこたん(makotan)の日記 このページをアンテナに追加 RSSフィード

makotangmail.com   

 

2016-09-27

C30K問題とC60K問題

だいぶ前にTomcatのフロントにnginx入れなかったら、入れないの??どうして??って質問されたのを思い出してふと書いてみる

その時は「必要ないから」ってだけ答えて詳しく説明してないけどw

歴史

ずっと昔


Apache - Axx - Tomcat 方式

ApacheをHTTPのネットワークインタフェースとして独自プロトコルTomcatと繋ぐ方法

ネイティブなApacheに静的ファイルを配置してTomcatは動的なファイルだけにすることで遅いTomcatを補完する方法



nginxが良かった頃


nginx - reverse proxy - Tomcat 方式

ApacheTomcatもBlockingIOなので、代わりにnginxをフロントに配置する方法

nignxがNon BlockingIOなのでTomcatが処理本体に集中して接続処理などはnginxが担当する


この辺りでNIOな各種方法がJavaでも出てきた

ちなみに既にApacheもNon BlockingIOなのが入ったのでnignxの優位性はそれほどない


最近

Tomcat単独方式

Apacheもnginxも必要ない

既にTomcatがNIOなのでクライアントから接続が来てもそれだけではスレッドを占有しない

例外はApache/nginx側のモジュールでゴニョゴニョしてからTomcatに引き渡したいとかレスポンスをゴニョゴニョしたいとき

静的ファイルはCDNに置くことを検討する


これから

No Tomcat方式

Javaでの開発ですらTomcat(=ServletAPI)であることのメリットが薄れる時代

最近作られてるJVMベースなWebフレームワークでは仕様化の遅いServletAPIよりnettyベースが多いことからそろそろServletAPIが終焉を迎える

処理としての自然な形での非同期化/小スレッド化を予想

静的ファイルはサーバ内部にそもそも持たずに積極的にCDNを使用して配布する


C30K問題とC60K問題

C30K問題はnginx - Tomcat方式で抱える接続数の上限問題

TCPのポート数が有限のためnginxとTomcatの間で3万程度で上限に来てしまう問題

Tomcatがさらに外部サービスに依存してたりするとこの上限はさらに下がる

nginxを外すことで随分緩和してC60K問題に変化する

あっ、ちなみにC30K/C60Kに達するにはOS側の設定変更が必須です


C60K問題解決案

TCPの接続元ポート数が有限である事を認識した上で・・・

サーバ間の接続を含めて効率的なポートの利用(HTTPからHTTP/2へ)などでポート数の枯渇を防ぐ

UDPの利用を検討する

少ないスレッドで効率的に処理をする(スレッド数分の処理しか行わないので結果的に消費するTCPポートの削減に繋がる)


というかそれ以前に・・・

そこまで必要か?って疑問を先に解決するべきだと思う

同時接続が1台のサーバ上で3万とか6万超えるサービス作ってたっけ?

それよりポチポチやって必要なときにインスタンス台数増やした方が楽じゃね?

みたいな疑問を持った方が開発中も幸せになると思う

2016-09-22

macapple watchでログイン

やってみた


とりあえず、macapple watchは最新にバージョンアップ


2段階認証してたので、解除して2ファクタ認証を有効にする

↑一番ハマったところ


mac側でapple watchログインを有効にする

最初にこれをやろうとするとエラーメッセージと一緒に2ファクタ認証を有効にしろって出る

このとき2ファクタ認証を受け取るのはSMS(なかなか通知が来なくて困ったけど後で判った)


時計付けたままmacをスリープにして、開くと・・・勝手にログインした!(≧▽≦)

mac2台でも同じ時計でログイン出来るし、これ凄いなぁ〜


2ファクタ認証すると2段階認証で有効だった通知受けとる端末たちが全部無効になるので、再度iCloudにログインし直すと通知が届くようになる

このOSなかなか面白いなぁ〜

2016-08-29

なんとなく最近気にしてること

まわりで騒がしいあれやこれやとは全く違ってて

  • 例外とエラーの扱い方
  • nullとnullの扱い方
  • 良いログとは

これらをしっかり作り込むのはなかなか難しい〜

そろそろ固まってきた様な気はするけど、まだまだ

2016-06-23

[]たった10年生まれるのが早かっただけ

今日、ぼーっとtwitterみてたらふと思った。

たった10年。されど10年


http://projects.spring.io/spring-statemachine/


全部手書きか可能なのにするとして、今の言語仕様を使うときっとこう作るなぁ〜って思う方法だったw

2016-06-06

CTK 開発をぼんやり想像してみた

Amazonが新規サービスを作る際にプレスリリースを先に作るという話とか

RestfulAPIがかなり多用されてきてる感じとか

マイクロサービスはサービス間もAPIベースでとか

そういうのをぼんやり見てて・・・ふと思いついた


APIを作成する前にCompatibility Test Kit(以後CTK)を別プロジェクト&仕様として作る

もちろん、APIの仕様を詳細化するに従ってCTKは追加されていく

APIのバージョンアップをする際には前のバージョンのCTKが全て通る=置き換え可能、前のバージョンのCTKの一部を改変する=互換性を失ったバージョンアップとなる

CTKの範囲外を実装した場合はCTKが通っても互換性を失う可能性がある(自己責任)ので、事前にCTK追加の手続きを取る

UnitTestとの違いはあくまでAPIを外から叩くテスト

エラー時の挙動もテストしたい場合はFault injectionをサポートする(運用時には停止する)


なんてことを考えたんだけど、SIっぽい開発でそこまで出来ないよなぁ〜

社内で作るAPIを長期で保守運用するなら良いかもしれないと思った


ふと思い出したけど、Buriの開発って内部APIまで含めてこんな感じだったw

別プロジェクトじゃ無かったけどね

 
東京の天気予報
-天気予報コム-
<< 2016/09 >>
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

makotanのアンテナ

1. 「S2Container.NET」を含む日記
2. 「s2dotnet」を含む日記
3. Hiroyasu Kitagawa’s Blog
4. IT総合情報サイト「ITmedia」Home
5. PukiWiki - FrontPageパターンWG
6. はてなダイアリー - 「S2Buri」を含む日記
7. あるSEのつぶやき
8. 「Seasar」を含む日記
9. inside out
10. HHa(H派)メモ
なかのひと あわせて読みたい