実践的な技術選択の考察

最近仕事で、パブリックデータウェアハウスからチーム自身のアカウントに属するクラウドストレージリソースにデータをエクスポートし、アプリケーションでそのようなリソースにクエリを実行する必要があります。データをエクスポートする必要がある理由は、データウェアハウスから直接データをクエリするのは低速で非同期のプロセスであるのに対し、アプリケーションのデータをクエリするのはリアルタイムである必要があるからです。この問題を解決するために、多くのAWSサービスから選択することができ、それらは基本的に2つの主要なカテゴリに分類されます：

最初のカテゴリーは、ストレージとコンテンツ配信です：

• CloudFront：CloudFrontは、異なる地域のユーザーにコンテンツを配信するために使用され、近隣のネットワークからのデータアクセスのエントリポイントとして機能する「エッジ」を世界中にいくつか持っています。大きなウェブサイト向けのCDN設備のようなものです。これは明らかに私が必要としているものではありません。
• S3: S3は生データや大きなオブジェクトを保存するのに適しており、データベースサービスよりも低コストです。最終的にファイルシステムを使ってデータを保存することになった場合、良い選択だと思います。また、GlacierにせよS3にせよ、ティアは概念的に最大であると同時に地域的なものなので、世界中の複数のノードが同じデータにアクセスする必要がある場合は、追加でデータを各地域に分散する必要があります。
• ストレージゲートウェイ：ストレージゲートウェイは、統合されたIT環境におけるオンプレミス展開のためのもので、ゲートウェイキャッシュやゲートウェイストレージの最適化に基づく最適化をサポートし、ローカルおよび隣接ネットワーク上のデータへの高速アクセスを容易にします。企業内の異なる地理的な場所でのファイル共有、イメージ、バックアップに使用できます。

• SimpleDB：DynamoDBと同様、非リレーショナルデータベースで、構造を自由に変更でき、データは自動的にインデックス化されるため、クエリが非常に高速です。SimpleDBはデータサイズが非常に小さく、典型的な使用方法としては、S3のファイルアドレスを保存するためにSimpleDBを使用することです。ただし、容量制限を考慮する必要があります。 1ドメインあたり10Gの制限しかなく、複数のドメインを作成することも可能ですが、その場合はアプリケーション自身がドメインをルーティングする必要があります。一貫性についてはDynamoDBと同じで、最終的な一貫性と強い一貫性を選択することができます。
• ElastiCache：MemcachedやRedisをクラウドに移動。
• RDS: RDSはリレーショナルデータベースをクラウドに移行することに相当し、DynamoDBやSimpleDBとの違いは主にRDBとNoSQL DBの違いです。
• RedShift: RedShiftは、カラム型ストレージ技術とノード間の並列分散クエリを使用し、POS上でのデータアクセスに最適化されたデータウェアハウスサービスです。

AWS上のこれらのデータベースサービスの違いは、1つの表にまとめてあります：

Jettyは、TomcatのBIOではなくNIOをベースにしてリクエストを処理するため、多数のコネクションを同時に処理し、長時間コネクションを維持する必要がある場合には、性能面で有利になります。 しかし、非常に短いコネクションライフサイクルや非常に頻繁なリクエストでは、TomcatがJettyを上回る性能テストデータが多数あります。Jettyは、TomcatのBIOではなくNIOに基づいてリクエストを処理するため、同時に多数のコネクションを処理し、これらのコネクションを長時間維持する必要がある場合、性能面で有利になります。しかし、非常に短いライフサイクルのリクエストや非常に頻繁なコネクションでは、TomcatがJettyを上回るという性能テストデータも数多く見つかります。

以下の抜粋は、Jetty VS Tomcatパフォーマンス比較からの両者の比較です：

Jettyの特徴と搭載。

• Full-featured and standards-based.
• Embeddable and Asynchronous.
• Open source and commercially usable.
• Dual licensed under Apache and Eclipse.
• Flexible and extensible, Enterprise scalable.
• Strong Tools, Application, Devices and Cloud computing supported.
• Low maintenance cost.
• Small and Efficient.

Tomcatの機能と搭載。

• Famous open source under Apache.
• Easier to embed Tomcat in your applications, e.g. in JBoss.
• Implements the Servlet 3.0, JSP 2.2 and JSP-EL 2.2 support.
• Strong and widely commercially usable and use.
• Easy integrated with other application such as Spring.
• Flexible and extensible, Enterprise scalable.
• Faster JSP parsing.
• Stable.

#p#

実装技術を選択する際、ある種の多肢選択問題がよく出題されますが、上記の2つの例は比較的合理的な分析と比較の例です。多くの場合、機能性、パフォーマンス、コミュニティサポート、拡張性とカスタマイズ性、既知の問題と制約などが考慮されます。

しかし皮肉なことに、考えてみれば、特定の技術を選択する最も重要な理由は、「合理的な分析」とはほど遠い、次のようなものなのです：

• "みんなが使っているから "というのは、例えばプロジェクトはJavaやC++をメイン言語として実装されていますし、私のように多くの人はあまり深く考えていないことが多く、思考の惰性になっているように思います。
• 「実際、これは悪いことではありませんし、私もプロジェクト・チームにいたことがありますが、ほとんどの人がリスクを心配して新しい技術の使用を拒否しました。しかし、プログラマーに技術を選択する自由を与えることは、長い目で見れば良いことです。すべての問題を "技術商人 "に任せていては、視野が浅くなるだけです。
• "私が知っているのはこれだけだから"、このケースの方が多いですね。なぜC3P0接続プールを選んだのですか？当時は他のデータベース接続プールを知らなかったからです．

技術者は常に技術選択においてある種のバランスを求めています。論文にはこの3つの理由は書かれていないかもしれませんが、心の中では意識的にせよ無意識的にせよ、この3つの理由に傾いているはずです。

小さなプロジェクトは技術的な視野を広げるのに役立つと言われていますが、似たような技術の長所や短所を比較・理解する術がないため、小さなプロジェクトだけでは技術そのものを知ることはできません。だからこそ、「トイコード」は新しいことを学ぶには最適ですし、技術共有のためのフィルムにもなりますが、エンジニアの継続的な成長にはつながらないのです。

そう思いますか？