Web App for Containers + MySQLでコンテナ対応したPHPアプリを作ろう! Yoichi Kawasaki
Web App for Containers は、アプリスタックのホストに Docker コンテナーを使用するため皆さんが今Linux上で利用しているOSSベースのアプリもアプリスタックごとDockerコンテナ化することでそのまま Web App for Containersで利用することができます。本ウェビナーでは簡単なMySQL + PHPアプリ(Wordpress)を題材に、アプリをコンテナ化し Web App for Containersにデプロイするまでの一連の流れを解説し、CIツールを使った継続的なデプロイ方法についてご紹介します。今回、AzureのフルマネージドMySQLサービスであるAzure DB for MySQLを利用して完全マネージドな環境でのアプリ実行を実現します。
2017/9/7 db tech showcase Tokyo 2017(JPOUG in 15 minutes)にて発表した内容です。
SQL大量発行に伴う処理遅延は、ミッションクリティカルシステムでありがちな性能問題のひとつです。
SQLをまとめて発行したり、処理の多重度を上げることができれば高速化可能です。ですが・・・
AP設計に起因する性能問題のため、開発工程の終盤においては対処が難しいことが多々あります。
そのような状況において、どのような改善手段があるのか、Oracleを例に解説します。
Web App for Containers + MySQLでコンテナ対応したPHPアプリを作ろう! Yoichi Kawasaki
Web App for Containers は、アプリスタックのホストに Docker コンテナーを使用するため皆さんが今Linux上で利用しているOSSベースのアプリもアプリスタックごとDockerコンテナ化することでそのまま Web App for Containersで利用することができます。本ウェビナーでは簡単なMySQL + PHPアプリ(Wordpress)を題材に、アプリをコンテナ化し Web App for Containersにデプロイするまでの一連の流れを解説し、CIツールを使った継続的なデプロイ方法についてご紹介します。今回、AzureのフルマネージドMySQLサービスであるAzure DB for MySQLを利用して完全マネージドな環境でのアプリ実行を実現します。
2017/9/7 db tech showcase Tokyo 2017(JPOUG in 15 minutes)にて発表した内容です。
SQL大量発行に伴う処理遅延は、ミッションクリティカルシステムでありがちな性能問題のひとつです。
SQLをまとめて発行したり、処理の多重度を上げることができれば高速化可能です。ですが・・・
AP設計に起因する性能問題のため、開発工程の終盤においては対処が難しいことが多々あります。
そのような状況において、どのような改善手段があるのか、Oracleを例に解説します。
A New Business Model of Custom Software Development For Agile Software Develo...Tsuyoshi Ushio
Successful business model of custom software for agile development.
22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering
November 16-21, 2014, Hong Kong
Easy to add, hard to remove. It is the case in many situations including software development, process improvements etc. How we can stay lean eliminating unnecessaries and be agile? We’ll explore the solutions with pattern mining workshop sessions. Stay Lean, Be Agile!
AgileRoots 2014
This slide is for Ultimate Agilist Tokyo in Japan. 2012.Nov.
I want to think about agile programmer's skill set. and I want to introduce ICAgile to Japan.
I analyzed agile value, principles, practices and ICAgile.
and participant members created some mandatory skill set in this session.
See this blog entry , that will be better.
http://simple-architect.blogspot.jp/2012/11/agile-programmers-skill-set-ultimate.html
About Agile Programmer's skill sets
Ultimate Agilist Tokyo 2012
This presentation will be used tomorrow. after that session I have a plan to update this slide.
【DLゼミ】XFeat: Accelerated Features for Lightweight Image Matchingharmonylab
公開URL:https://arxiv.org/pdf/2404.19174
出典:Guilherme Potje, Felipe Cadar, Andre Araujo, Renato Martins, Erickson R. ascimento: XFeat: Accelerated Features for Lightweight Image Matching, Proceedings of the 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2023)
概要:リソース効率に優れた特徴点マッチングのための軽量なアーキテクチャ「XFeat(Accelerated Features)」を提案します。手法は、局所的な特徴点の検出、抽出、マッチングのための畳み込みニューラルネットワークの基本的な設計を再検討します。特に、リソースが限られたデバイス向けに迅速かつ堅牢なアルゴリズムが必要とされるため、解像度を可能な限り高く保ちながら、ネットワークのチャネル数を制限します。さらに、スパース下でのマッチングを選択できる設計となっており、ナビゲーションやARなどのアプリケーションに適しています。XFeatは、高速かつ同等以上の精度を実現し、一般的なラップトップのCPU上でリアルタイムで動作します。
セル生産方式におけるロボットの活用には様々な問題があるが,その一つとして 3 体以上の物体の組み立てが挙げられる.一般に,複数物体を同時に組み立てる際は,対象の部品をそれぞれロボットアームまたは治具でそれぞれ独立に保持することで組み立てを遂行すると考えられる.ただし,この方法ではロボットアームや治具を部品数と同じ数だけ必要とし,部品数が多いほどコスト面や設置スペースの関係で無駄が多くなる.この課題に対して音𣷓らは組み立て対象物に働く接触力等の解析により,治具等で固定されていない対象物が組み立て作業中に運動しにくい状態となる条件を求めた.すなわち,環境中の非把持対象物のロバスト性を考慮して,組み立て作業条件を検討している.本研究ではこの方策に基づいて,複数物体の組み立て作業を単腕マニピュレータで実行することを目的とする.このとき,対象物のロバスト性を考慮することで,仮組状態の複数物体を同時に扱う手法を提案する.作業対象としてパイプジョイントの組み立てを挙げ,簡易な道具を用いることで単腕マニピュレータで複数物体を同時に把持できることを示す.さらに,作業成功率の向上のために RGB-D カメラを用いた物体の位置検出に基づくロボット制御及び動作計画を実装する.
This paper discusses assembly operations using a single manipulator and a parallel gripper to simultaneously
grasp multiple objects and hold the group of temporarily assembled objects. Multiple robots and jigs generally operate
assembly tasks by constraining the target objects mechanically or geometrically to prevent them from moving. It is
necessary to analyze the physical interaction between the objects for such constraints to achieve the tasks with a single
gripper. In this paper, we focus on assembling pipe joints as an example and discuss constraining the motion of the
objects. Our demonstration shows that a simple tool can facilitate holding multiple objects with a single gripper.
Function App 作成の要求
ARM がリクエストを Geo-Master に送信
Geo-Master が適切な Scale Unit を選んでリクエストを転送
Scale Unit が Function App を割り当てる
Function App 作成の要求
ARM がリクエストを Geo-Master に送信
Geo-Master が適切な Scale Unit を選んでリクエストを転送
Scale Unit が Function App を割り当てる
サポートサーバの用途は、冗長性やスケールのためのインスタンスになっている。
Fig 1. 先にプロビジョンされたプールが存在する
Fig 2. App Service Plan で、2つのサーバーを割り当てる
Fig 3. 2 つのワーカーを追加する。ワーカーは既にプレプロビジョンされて、ウオームアップされている。
あとはアプリをWorker にデプロイするのみ。デプロイできたら、ワーカーはローテーションに入り、Front End が
トラフィックをアロケートする。このプロセスは数秒かかる。
Fig 4. 複数のApp Service Plan を示している。これは複数の顧客が含まれている
ポイント: Function App は、Azure File をローカルのように使う(だから、Node.js の時にたくさんファイルがあると速度が遅くなる)
Azure File の性能要件を調査する
API Controller は Geo-Master の extension. Geo-Master は Scale Unit にマネージメントオペレーションを委譲する。
Function App を作ることや、アプリケーションのリスタートなども。
Publishers : Application デプロイ用の API 。コンテンツは、 Blob にストアーされて、ファイルサーバーにマップされる。Publisher は、顧客に
FTP アクセスを提供する。コンテンツとログについて。アプリケーションのデプロイは複数の方法がある。WebDeploy (Visual Sutido)
GitHub 等をつかった、Continous Deployment ほかにも Run from Zip デプロイもある
SQL Azure : Function App のメタデータを保持する。どの Function App がどの Scale Unit に割り当てられているか?が保存されている。
また、アプリケーションのランタイム情報も保持している
Data Role : Function App の設定情報は、SQL Database に存在するが、そのキャッシュレイヤー DataRole は、Front End と同じところに存在する。
Blob Storage の部分は以前は、Azure File だったが、SMB Share とカスタムファイルシステムドライバに変更された。Azure File よりこちらのほうがずっと高速である。
複数のFunction App は、1 つの App Service Plan に割り当てられる。
App Service Plan に含まれるすべての‘Function App は、App Service Plan で割り当てられたすべてのワーカー(サーバー)で実行される。
複数のコンピュートリソースが App Service Plan に割り当てられたところを想像しよう
App Service Plan は 10 のコンピュートリソースがある。
Function App が 50 あるとする。
50 のすべてが最初のサーバーから、10番目のサーバーすべてでで起動する。
この状態で、App Service Plan がより多くのリクエストをうけて、CPUとメモリを改善したいためにスケールしたとしても、スケールしたところで
動いているAPPの数は同じになるので、性能は改善されない。
その代わりに、 50 のアプリを分割する
・ 40 の low-volume アプリケーション は1つの App Service Plan にわりあてて、1つのコンピュートリソースを確保する
・ 5 の mid-to-low volume のアプリケーション を 2個目の App Service Plan それは、1つのコンピュートリソースを確保する
・負荷の高い 5つのアプリケーションは、それぞれ別の App Service Plan にわりあてる。App Service Plan をスケール In/Out すると
CPU / Memory の利用状況の改善になる。
こうすると、効率的にリソースを割り当てて、別々にスケールアウトできるようになる。
他の方法としては、Per-App スケールという方法がある。先ほどと同じの50の Function App の例で考える。 一つの App Service Plan を作る。
・ 40 の low-volume の Function App は、 最大 1 つのサーバーで動くように制限する
・5つの mid-to-low は、最大2つのサーバーに
・ 5つのハイボリュームのFunction App は、最大 10 のサーバーの制限をつける
App Service Plan は、最小のサーバーから初めて、オートスケールに茂登枝く。 結果として、インスタンスのサーバーが起動する
Application Slot の注意
アプリケーションスロットは、デフォルトでは新しい、 Function App を同じ App Service Plan で動かしているのと等しい。
しかし、同じ App Service Plan の すべての Function App はすべてのサーバーで動くため、負荷テストを、ステージングスロットにかけると、
本番の方にも影響がでることになる。
それを避けるためには次のようにする。
・ 新しい App Service Plan をスロットように作る。両方の App Service Plan は同じリージョンであること
・ ステージングのスロットを新しい App Service Plan にする
・ 負荷テストをする
・ スワップ可能になったら、ステージングスロットの App Service Plan をもとにもどす
・ スワップする
ノーダウンタイムデプロイメント
・スワップを使う
・スワップは再起動とかおこなわないので、ウォームアップが必要なら、ステージングでやっておくとよい
・コントローラーが Front-end ロードバランサーに通知して、トラフィックがリダイレクトされる
Scale Unit ネットワークコンフィグレーション
・ App Service の Scale Unit は、 Cloud Service にデプロイされる。
・ Scale Unit は、 一つの Virtual IP を持つそれは世界に公開される。VIP は、 Cloud Service のどの Scale Unit がデプロイされているかを表している。
・ App Service は、 HTTP:80, HTTPS 443 のみ。
・インバウンド IP のみが確保される。 Front End は、SSL のターミネーションも実施している。
Public VIP
inbound Http トラフィックを受け付ける。 Nslookup とかで見ると中身が Cloud Service とわかる。
outbound VIP は、App Service Plan の Function App の Property に Out bond IP が5つのVIPが
がある。1つの Public VIP と、4つの Outbound IP がわりあてられている。 Consumption Plan の Outbound IP はない
App Service Environment だと、IP を確定できるが、 Functions にはない。
ネットワークポートの注意(ポイント)
・ outbound のネットワーク呼び出し(REST や DB 等)の呼び出しには注意が必要
・ Function App からの外部ネットワーク呼び出しは、Azure Netwrok の NAT マッピングに依存する。
新しい NAT マッピングのエントリを作ることは、時間がかかる 1つのスケールユニットについて、NATマッピングの数が限られる。 App Service は、outbound コネクションに
たいして、次の制限がある。
・ 1,920 コネクション (B1/S1/P1) インスタンス
・ 3,968 コネクション (B2/S2/P2) インスタンス
・ 8,064 コネクション (B3/S3/P3) インスタンス
・ 64k max 上限 per App Service Environment (Function App には関係なし)
この上限を超えると、function App は失敗しだす。こんなエラーをみることになる。 “An attempt was made to access a socket in a way forbidden by its access permissions aa.bb.cc.ddd.”
これを避けるためには次のベストプラクティスが有効
・ADO.NET/EF などのデータベースコネクションプーリング
・ php/mySQL には、 persistent database connections
・ Node には、outbound HTTP/HTPS コールを keep-alive を設定する。Outbound が再利用されるように
・ .NET アプリケーションには、HttpClient をプールし再利用する。Keep-Aliveを設定する。System.Net.ServicePointManager.DefaultConnectionLimit を増やす。
そうでなければ、2つのアウトバウンドコンカレントリクエストに制限されてしまう。
他の制限が App Service Sandbox に存在する。(必見)
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
PDFも使えるのが決まっている。
ScriptHost の実行は何から行われるか?
V1 : IIS (w3wp.exe) V2: dotnet.exe or node.exe with local IIS as a reverse proxy
Funciton App の中で、何個の ScriptHost が実行されるか? -> 1 つ。 CPU とメモリが、ScriptHost そしてそこの上で動いている Functions でシェアされる。
コンサンプションプランの場合の、スリープの振る舞いは?:
ファンクションアップは、 20分でアイドルになる。そして、VMからアンロードされる。
もし、新しいリクエストがやってきたら、 Front End がData Role に問い合わせてどのVM が適切かを見極めてアサインし、ファンクションのランタイム (Script Host) をスタートする。実際のコールドスタートは、様々なケースがある。例えば、ホスティングプラン (App Service Plan, コンサンプション) , Function Runtime (V1, V2) 言語、読み込む必要のある言語にもよる。 (現在質問中)
Front end は、どこにホストされているか?どの程度の Worker を担当するか?
フロントエンドは、Azure App Service のインターナルVMに存在している。普通は A2, A3 のVMでできている。実際の数とかサイズは場合による。
通常は、8 – 20 Worker : 1 FrontEnd 割合はどれぐらいビジー化によって決まる。 1つの Front end につき大抵は数百の Worker を担当する。ただ、数千もの Workerを担当する場合もある。
コンサンプションプランの最初のVM の割り当て
基本的に1台のVMに割り当てられる。ただし、バーストモード以外。
コンサンプションプランでの、App Service Plan の共有はできない。
Scale Controller が使っているモニタリングツールは?
スケールコントローラーがカスタムトリガーをモニタリングしている。あるケースでは、ポーリングデータのデータキャッシュをみている。タイマーでは、クーロンのスケジュールをパースして、低k実行の1分前に Function App がプロビジョニングされるようにしています。
タイトルはあまり意味がない。
説明したいことが複数あるばあいは、スライドをわけるか視点誘導する
図はそのままでルーペを使って視点誘導をする
サーバーの上限は200
ScriptHost の実行は何から行われるか?
V1 : IIS (w3wp.exe) V2: dotnet.exe or node.exe with local IIS as a reverse proxy
Funciton App の中で、何個の ScriptHost が実行されるか? -> 1 つ。 CPU とメモリが、ScriptHost そしてそこの上で動いている Functions でシェアされる。
コンサンプションプランの場合の、スリープの振る舞いは?:
ファンクションアップは、 20分でアイドルになる。そして、VMからアンロードされる。
もし、新しいリクエストがやってきたら、 Front End がData Role に問い合わせてどのVM が適切かを見極めてアサインし、ファンクションのランタイム (Script Host) をスタートする。実際のコールドスタートは、様々なケースがある。例えば、ホスティングプラン (App Service Plan, コンサンプション) , Function Runtime (V1, V2) 言語、読み込む必要のある言語にもよる。 (現在質問中)
Front end は、どこにホストされているか?どの程度の Worker を担当するか?
フロントエンドは、Azure App Service のインターナルVMに存在している。普通は A2, A3 のVMでできている。実際の数とかサイズは場合による。
通常は、8 – 20 Worker : 1 FrontEnd 割合はどれぐらいビジー化によって決まる。 1つの Front end につき大抵は数百の Worker を担当する。ただ、数千もの Workerを担当する場合もある。
コンサンプションプランの最初のVM の割り当て
基本的に1台のVMに割り当てられる。ただし、バーストモード以外。
コンサンプションプランでの、App Service Plan の共有はできない。
Scale Controller が使っているモニタリングツールは?
スケールコントローラーがカスタムトリガーをモニタリングしている。あるケースでは、ポーリングデータのデータキャッシュをみている。タイマーでは、クーロンのスケジュールをパースして、低k実行の1分前に Function App がプロビジョニングされるようにしています。
タイトルはあまり意味がない。
説明したいことが複数あるばあいは、スライドをわけるか視点誘導する
図はそのままでルーペを使って視点誘導をする
3つの理由でパフォーマンスを改善した
1. Worker VM は、たくさんのHTTP トラフィックが一度にくると簡単にアップアップになっていた。我々はこれを、同時リクエストが来たら、複数のVMにバースト(炸裂)させるようにした。
2.昔は、新しい Worker を追加するのが遅かった
a. Scale Controller と Front End のフィードバックループが遅かった(10秒に1回のチェックで、30秒に1回しかVMを足さなかった)
b. コールドスタートは、スケールアウトを遅くしていた。なぜなら我々はトラフィックをルーティングするまでに、コールドスタートが終わるのをまっていた。
我々は、a を解決し、bを、Front End でスケールの決定をオンデマンドで実施するようにした。Scale Controller が定期的に決定するよりも。
3.Front End は、ラウンドロビンを使っていた。これは、ダイナミックにVMが足された場合よくなかった。今は、Weight / Concurrency ベースのアルゴリズム(chris作)に移行した。