Typemock: その過去・現在・未来
Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。
作者 Scott Delap, 翻訳者 八角研究所 投稿日 2008年6月12日 午後8時4分
Oracle の Cameron Purdy 氏は JavaOne 2008 においてスケーラビリティに関するトピックを提示した(source)。彼の話は JavaOne の多くのセッションとは違って特定の Java ライブラリにフォーカスをあてたものではなく、アーキテクチャとデザインの一般的な原則をプラグマティックで良識のある角度から見直したものだった。 Purdy 氏によると、問題は一般的に 10 のステップにブレークダウンできるという。10 - 問題を理解するスケーラビリティがアプリケーションを高速化しないことはみんな知っている。スケーラブルなシステムは通常シングルユーザのシステムよりも遅い。Ruby を使っている Twitter のスケーラビリティに関する最近の議論を考えると、「アーキテクチャはテクノロジに勝る」という点に注目するのも面白い。彼はおどけた調子で「 Windows だってスケールできた」と述べ、理にかなった技術的懸念として、予測不能な CG のスケジューリング、スレッドスケジューリング制御の欠如、非同期 I/O の欠如、を挙げた。
9 - やるべきことを決める
8 - アーキテクチャはテクノロジに勝る
7 - 基本を理解する
6 - ネットワークを視覚化する
5 - デザインを視覚化する
4a - 過負荷に備える
4b - パーティションで拡張性を高める
3a - 障害に備える
3b - レプリケートで可用性を高める
2 - 理にかなったレイヤ構成
1 - 単純化する
Purdy 氏は続けて、スケーラブルなステートフルシステムを構築するという挑戦は、システムを管理しやすく実用的なものにする一方で、可用性、信頼性、拡張性、そして性能を達成することだと述べた。この点についてプレゼンテーションはステートフルなスケールアウトの五つのパターンにフォーカスを当てている。
信頼性のあるルーティングは、パーティショニングとレプリケーションをサポートするステートフルなスケールアウトを実現する基本的な要素として説明された。最後の、そしてもっとも重要なトピックは単純化だった。複雑さは信頼性の敵だと Purdy 氏は言う。複雑なシステムは有限の状態をもつアーキテクチャとしてモデル化できるべきだ。ホワイトボードの上で動かしてみることができないものは、運用環境でも動かないと断言できる。
原文はこちらです:http://www.infoq.com/news/2008/05/scaling-out
この論文では、仮想化やクラウドサービスの複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。
Fiberはユーザに試練を課すことなくこの考えを実装する有益な並行性ツールとして、ライブラリが2つあります。まさにこのためのソリューションとしてあるのがNeverBlockライブラリです。私たちはNeverBlockプロジェクトのMohammad A. Ali氏とRevactorライブラリのTony Arcier氏に話を聞きました。
システムの保守容易性や拡張性を確保するためのベスト・プラクティスに関する記事は数多くありますが、この記事では避けた方がいい、いくつかの悪習慣(ワースト・プラクティス)を強調します。
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
No comments
返信