PHP開発者が分散アプリケーションを構築する際に警戒する必要がある8つの誤解
Peter Deutschは、1997年に分配コンピューティングについて7つの誤解を提案し、後にJames Gosling(Javaの父)を追加しました。これらの誤解は、Mashup、SOAPおよびRESTサービスと対話するアプリケーション、Facebook、Google、Twitter APIを介したユーザー認証、リモートデータベースやキャッシュサービスからの情報の取得など、毎日分散アプリケーションを構築するため、PHP開発者にとって重要です。私たちが構築するのは、分散コンピューティングアプリケーションです。したがって、これらの8つの誤解とその意味を理解することが重要です。
キーポイント:
-
-
- ピーター・ドイツとジェームズ・ゴスリングによってプロモーションされた8つの分散コンピューティング誤解がPHP開発者に不可欠です:ネットワークの信頼性、ゼロレイテンシ、無限の帯域めい、ネットワークセキュリティ、単純なトポロジー、ゼロ
- ネットワークの信頼性と帯域幅の大幅な改善にもかかわらず、これらの要因は完全ではありません。開発者は、潜在的な障害を予見し、アプリケーションの設計と展開に対応する処理戦略を組み込む必要があります。
サイバーセキュリティは常に重要な問題であり、開発者は優れたセキュリティ慣行に優先順位を付け、パートナーのセキュリティ対策を評価する必要があります。
- 開発者は、トポロジーの変化、サプライヤーの変更の可能性、およびデータ送信に関連するコストに対処する準備をする必要があります。また、ネットワークが同型であると仮定することなく、複数のデータベースとデータソースを処理できる柔軟なアプローチをとる必要があります。
ネットワークは信頼できます- これは明らかに間違っています。ネットワークの遅延は減少し、1995年以来帯域幅は大幅に増加していますが、ネットワークが信頼できると言うのは間違っています。あまりにも多くのサービスを使用しない簡単なアプリケーションを構築するとします - MySQLをバックエンドとして使用するPHPアプリケーション。問題はないようです。ただし、後でXeroundなどのMySQLホスティングプロバイダーを使用してデータベースのニーズを満たすことにしたとします。優れたスケーラビリティと高可用性があっても、システムに問題がある場合はどうなりますか?インフラストラクチャがDDOS攻撃に見舞われたり、内部の問題によりダウンタイムがある場合はどうなりますか?多くの場合、約99.999%の稼働時間を聞きますが、それでも100%ではありません。サービスの急増と今日では通常非常に利用可能な帯域幅により、完璧なものは何もないことを忘れがちです。アプリケーションのサービス障害をどのように検討しますか?
遅延はゼロ
これは悪いことですか?混合。アプリケーションの構造と利用可能なリソースに応じて、遅延の問題を大幅に軽減できます。 Amazon Web Servicesなどのサービスを使用してアプリケーションをホストし、S3を利用して、データが世界中の複数の地域に配置され、エンドユーザーに近づき、Web上のアプリケーションの遅延を減らすことができます。しかし、たとえレイテンシを減らすことができたとしても、それを排除することはできません。さまざまな方法とアーキテクチャを採用して、私たちへの影響を減らすことができますが、私たちが何をしても、それは常にそこにあります。アプリケーションを設計するときにこれを検討しましたか?
- 無制限の帯域幅
帯域幅は本当に無制限ですか?もしそうなら、無限の価格はいくらですか?ネットワークがますますモバイルに向かっていると考えると、古いものはすべて生まれ変わります。ダイヤルアップアクセスの速度で始めたと言っているわけではありません。更新された4Gネットワークは、以前の2Gおよび3Gネットワークよりもはるかに高速です。ただし、現在、ピークデータレートでさえ、標準のブロードバンド接続よりも低くなっています。さらに、モバイルブロードバンドの人気により、当社のサービスを使用しようとしている潜在的なユーザーの数(私たち全員が人気があり、少なくともFacebookの成功の一部)が驚くべき速度で成長しています。 Mobithinkingのこれらの統計を検討してください:
- 59億人のモバイルユーザーがいます。
3Gカバレッジを持つ12億人のモバイルネットワークユーザー。 -
モバイルデバイスは、グローバルクリックの8.49%を占めています。 -
これを考慮して、帯域幅率と世界中の浸透が増加している間、ユーザーの成長率がこれを相殺していると言ってもいいです。さらに、モバイルブロードバンドによって提供される膨大な柔軟性により、明確な一時的なサービス消費が自然に現れました。サービスの潜在的に巨大な負荷の準備ができていますか?この可用性によって引き起こされるピークを処理できますか?
サイバーセキュリティ-
それがあまり詳細になく、それが常に間違っていると言うのは公平だと思います。ご質問がある場合は、LinkedInまたはeHarmonyメンバーに相談する必要があります。アプリケーションを設計および展開するとき、アプリケーションのホストされた場所(Rackspace、Pagodabox、CloudControlなど)およびアプリケーション自体の設計にどの程度の努力をセキュリティに取り入れますか? SecurityAffairsによると、Prolexicレポート:
金融サービス業界を対象とした悪意のあるパケットトラフィックは、月ごとに3,000%増加しました。 -
2011年第4四半期の金融サービス業界の悪意のある交通データの量は、19.1TBと140億パケットであり、2012年の増加でした。 -
2012年には、特定され緩和されたデータの量は65TBで、データパケットは1.1兆、2011年の80倍でした。
-
ネットワークが安全でないことを考えると、当然のことながら、良いセキュリティプラクティスを使用していることを確認する必要があります。 Chris Shiflettのブログ、Essential PHP Security、PHP Security Allianceなどからの優れたアドバイスが膨大になることを考えると、アプリケーションコアにセキュリティを組み込む方法とその理由を知らないことは困難です。あなたのセキュリティ慣行は何ですか?展開したベンダーを評価しましたか?
トポロジーは変わらない
じゃない?本当に?それは変わりません、または私たちはただ知りませんか?アプリを他の人にホストするとき、私たちは知りません。プロバイダーがデータセンターを再構成する場合は、アップグレードし、調整してください。トポロジは何らかの理由で変化します。前述のスマートフォン使用の増加を考慮して、トポロジは頻繁に変化します。ユーザーとプロバイダーの観点から見ると、トポロジはほぼ毎日変わります!トポロジが変更され、それが依存する外部サービスがアクセスできなくなった場合、たとえばデータベースにアクセスできない場合、これは間違いなく問題です。ただし、プロバイダー内に変更があり、アプリケーションが実行され続けている場合、問題にならない場合があります。もちろん、Simple Configurationで小規模でホストされたアプリケーションを簡単に記述するのは簡単です。しかし、アプリケーション、特にますます人気があるアプリケーションは変わります。あなたはあなたのデザインのトポロジカルな変化を考えましたか?アプリケーションの設計と展開設計の失敗をどのように説明または対処しますか?
1人の管理者のみ
-
"しかし、私のアプリケーションは単一のサービスプロバイダーによってホストされています。オペレーティングシステム、データベース、Webサーバーのサポートを提供しています」とあなたは言いました。 OK、それがあなたのアプリケーションであると仮定すると、それは本当に1つの管理者だけですか?実際に1つの管理者しかいなかった場合、プロバイダーがアプリケーションを処理すると本当に信じていますか?彼らが病気であるか休暇中に、私は何が起こるかを考えるのが嫌いです。多くの場合、少なくとも少数の管理者が存在しますが、各管理者の技術的およびより広範な洞察力が異なる場合があります。ネットワーク侵入検知やその他のセキュリティポリシーなどの戦略を開発する必要がありますが、それらがすべて同じ徹底とデューデリジェンスに準拠するという保証はありません。今日利用可能な多数のホスティングプロバイダーとDNSレコードの更新にかかる時間が少ないことを考えると、多くのオプションと柔軟性があります。あるプロバイダーがニーズや期待を満たさない場合は、別のプロバリに頼ることができます。これがあなたにどのように影響するかを考えましたか?サプライヤーを簡単に変更できない場合はどうなりますか?多数のベンダーのロックインがある場合、またはモバイルコストが高い場合はどうなりますか?アプリケーションアーキテクチャが十分に柔軟でない場合はどうなりますか?この種のリスクを軽減するために、どのようなステップができますか?
-
送信コストはゼロ
です
これまでのすべての声明と同様に、この妥当性はありそうにありません。当社のアプリケーションをサポートするサーバーが同じデータセンターの同じラックにある場合、転送コストは大幅に削減できますが、時間コストの観点からです。お金の費用はどうですか?はい、必要に応じて無限に縮小して縮小することができます。また、エンドユーザーにできるだけ近くにあるように、ジオディスパースデータセンター間にアプリケーションデータを保存できますが、価格はいくらですか?アプリケーションまたはサービスの建築構成は何ですか?コストや時間の面でゼロに近いですか? 1つを減らすことができれば、別のものを追加しますか?
- ネットワーク同型
他の誤解とは異なり、PHP開発者として、私たちはこれを理解するために生まれたと思います。 Windows、Linux、Solaris、BSD、Mac OS Xサーバーでアプリケーションをホストしています。 MySQL、SQLServer、SQLite、PostgreSQL、MongoDB、Hadoop、およびOracleを使用してデータを保存します。異なるインターフェイスを必要とするXMLまたはJSONを介して外部サービスを使用します。マルチ操作システムおよびマルチサービスコミュニティとして、初期から等型ネットワークを期待したことがないと言えるでしょう。しかし、質問はまだ尋ねる必要があります、あなたの方法は柔軟ですか?複数のデータベースとデータソースを処理できますか?抽象工場などの関連する設計パターンを使用して、透明なコードインターフェイスを使用してさまざまなソースやタイプからデータを消費しますか?または、XMLからJSONに切り替えるのと同じくらい簡単なことをする必要がある場合、コードは壊れますか?
結論
PHP開発者として、分散コンピューティングの8つの誤解は以前と同じくらい重要だと思います。利用可能な膨大な量の情報とリソースを考えると、私たちはそれらを理解し、発生するリスクを軽減するために非常に有利な立場にあります。どう思いますか?アプリケーションとサービスを開発する際にそれらを検討しますか?これらの8つの誤解があなたのアプリケーションにどのように影響すると思いますか?
(写真は変わらないままです)
以上がPHP開発者向けの分散コンピューティングの8つの誤りの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。