→IaC(Infrastructure as Code)
→ネットワーク関連
→Web技術関連
→仮想化技術
一般 †
AWS †
Microsoft Azure †
GCP †
→Google関連
→Google App Engine関連
- GCPサーバレスサービスの比較 - Qiita 2021
- CloudFunctionとCloud Run
| Cloud Functions | Cloud Run |
トリガー | HTTP or Event | HTTP |
実装方法 | 関数 | Container or GKE |
language | JS/Node.js, Python, Go | 言語、ライブラリに依存せずなんでも使える |
- 大きな違いは実装方法がFunctionsの方は関数で実装しなければならないので使用できる場面が限定的であるのに対し、Cloud Runではコンテナーベースの実装となっているため、ライブラリや言語に依存せずに柔軟に使用することができます。また、Cloud RunはGoogle Kubernates Engine(GKE)にもデプロイすることができ、これにより、ステートフルなサーバレス環境を構築することができる
その他のクラウドベンダー †
- Google App EngineとAmazon EC2は世界に新しい革命をもたらすか 2008.4.9
- Amazonは、EC2だけでなく、S3やSimpleDBのような、Webサービスインフラビジネスを積極的に進めている会社で、海外のサーバソリューションでは、最初からAmazon EC2向けのライセンスを発行するところも増えてきた。
- Google App Engineは、プロフェッショナルユースで使うとなるとかなり勇気がいる。10GBを超えてしまったらどうするのか。そのケアが全くない
- AmazonはWeb-APIを利用してもらえばもらうほど自社が儲かるというビジネスモデルだから、Web-APIに対する制限はとても緩いが、GoogleはWeb-APIだけを利用されるとGoogleにとってのうまみが全くないので、Web-APIというのはあくまでも学生実験レベルの小規模で限定的なものとして公開せざるを得ないし、実際のところGoogleのWeb-APIだけを使って画期的な検索エンジンをつくるモチベーションというのはとてつもなく低い。
- EC2には動作が重いという根本的な問題がある。料金はリーズナブルだが
- Googleは開発言語がPythonのみというのも引っかかる部分
マイクロサービス/クラウドネイティブ †
→コンテナ型仮想化
- マイクロサービスの次に来るかもしれない言葉について - arclamp 2021.9
- Microservicesとは巨大システムでアジャイルを機能させる構造のことであり、その構造を支えたのがDevOps /NoOp
- たとえば、Microservicesに取り組むならAgileとDevOpsは前提であり、ここに組織が慣れていないなら、実現は不可能です。逆に言えばAgileとDevOpsを実現していけば、自然にMicroservicesになっていきます。だって、それが歴史なのですから。
- バルクヘッド パターン 2021.10
- マイクロサービスにおけるデザインパターンの一つ
- リソースを分割し、1 つのサービスの呼び出しに使用されるリソースが別のサービスの呼び出しに使用されるリソースに影響しないようにできます。 たとえば、複数のサービスを呼び出すコンシューマーに、各々のサービス用の接続プールを割り当てることができます。 サービスが失敗し始めると、そのサービスに割り当てられている接続プールのみに影響し、コンシューマーは他のサービスを引き続き使用できます。
Istio †
Firebase †
ASP/SaaS †
- 中堅・中小企業ではコスト増も
- 基幹業務系でも非定型業務系でも利用者が499人以下の場合、トータルコストが50%以上上昇したという回答が10%を超えている。特に、基幹業務系ではコストが増えた回答者が減った回答者よりも多く、平均すると10.0%上昇している。非定型業務系では平均1.0%コスト削減と、ほとんどコストメリットは出ていない。
- 一方、500人以上の利用者がいる場合、基幹業務では6.6%、非定型業務では15.8%と明らかにコスト効果が表れている。SaaS/ASPは中堅・中小企業に向くと言われているが、コスト面で見る限り、利用人数が多いほどメリットが大きくなる。
レンタルサーバ/VPS †
→ファーストサーバ事故に関してはシステム運用にまとめた
- VPSとは?レンタルサーバーと何が違う?分かりやすく解説 2020
- VPSでは1台の物理的なサーバーの中に、仮想的に複数のサーバーを構築します。共用サーバーと異なり、ホストOSの土台の上にユーザーごとにゲストOSが用意されており、基本的にこのゲストOS同士は干渉することはありません。そのため、共用サーバーのように、他のユーザーの利用の影響によって障害などが発生したり動作が重くなってしまったりということは基本的にはありません。
- 専用サーバーは物理的なサーバーを1台まるごと利用できるサービスです。一方のVPSは、仮想的に専用サーバーを利用するといっても、物理サーバーを専有しているわけではありません。
- ロリポップのPHP4からPHP5へ変更に伴うPukiWikiの設定変更
- イロイロ調べてみるとロリポップのPHP4はApacheのモジュールとして動作していたらしく、PHP5はCGIとして動作するようだ。
- ここでPHPの挙動やパーミッション周りの設定に違いが出るようで、大体それでとらぶってるみたい。
- PukiWikiの認証機構はBasic認証とかDigest認証に頼っている。これはWebサーバとブラウザ実装の問題であって、PukiWiki自体は設定ファイルに基づいて操作してるだけだ。
- つまり認証自体がApacheの機能をチョイと借りているわけで、CGIのように単独で動くものバージョンではその機能が無い。つまりPukiWikiの認証機構はCGI版では動作しなくなる
- lolipopのメールサーバへのSMTPがOP25B(Outbound Port25 blocking)にひっかかってメール送信できない場合