スーツ姿が大多数を占める，普通の「企業向けセミナー」な感じでしょうか．一人だけ黄色いTシャツだったので，見た目には目立ったかな(ぉ．
後半はNTTデータの宣伝のような雰囲気になってきたので退散．
##メモと感想
- サーバ統合でサーバ利用率は上昇するが，利用状況と頻度・アクセス時間帯などの統合的な状況を判断して統合する必要がある．
- 深夜のバッチサーバと昼間の Web/App サーバの統合など
- 統合によりサーバ環境が変化する場合もあり得る．
- サーバソフトウェア が常時 Active になったりなど．
- 問題はネットワークかもしれないとき．
- スペック上問題はなくても，実行値・実測値的には問題に．
- 例えばスイッチでアドレステーブルを処理するときに，16384 件目までは ASIC を使うが，それ以降は CPU 処理だったとか．
- どこもやはりデータベースのチューニングは必須．
- テーブル分割・負荷分散など
- 性能要件をしっかり踏まえた設計・開発をしなければ，将来的にコスト負担が大きくなる．
- インフラ設計にもアプリエンジニアも関わるべき．
- 単独で解決できるほど，単純ではなくなってきているし，アプリ設計がインフラに影響を及ぼす場合もあるから．
- 大は小を兼ねない場合もあるのは知っておくべき．
- 必要な部分に必要なコスト(人力・機材など)を投入すること
- 落とせないサービス・サーバには活性挿抜できるサーバが重要
====
##Web システムにおけるトラブル傾向とその事例 ###統合時の問題
- 事例
- 19台の App サーバを 2台の UNIX サーバに統合
- キャパシティ・プランニングはしたが，メモリーリークによってスワップ発生していた
- 夜間停止していた JavaVM が常時稼働になったため，メモリリークや GC がうまく効かない状況に陥っていた．
###性能が追いつかない場合
- コンシューマ向け，携帯向けサービス
- まるでうちの会社のような問題
- 問題はネットワークだった．
- スペック上問題はなくても，実行値・実測値的には問題に．
- 例えばスイッチでアドレステーブルを処理するときに，16384 件目までは ASIC を使うが，それ以降は CPU 処理だったとか．
###もうどうしようもない状況で
- これもうちの会社のような・・・・
- 最大の効果は，やはりデータベース・テーブルのチューニング．
##プラットフォーム安定稼働設計のポイント
- 安定稼働 = ビジネスが継続できること
- 安定稼働 = 可用性・保全性・キャパシティ
###高可用性設計(Web システムの可用性)
- クラスター構成
- Hot Standby 構成(ホット・フェイルオーバ)
- DB クラスタ / VM クラスタ / WebApp クラスタ
- ロードバランサによる冗長構成
- グローバルロードバランス
- 東京 -> 大阪 など
- プロトコルレベルの冗長化
- フォールト・トレラント
- 可用性設計のポイント
- 多階層・強調動作システムである
- 各階層で最適な技術を用いること
- 各階ではひとつの技術を用いること．複数技術は御法度．
- HTTP はセッションレスプロトコルである
- App 側がセッションを管理していることを忘れない
- ある部分ではセッション引き継ぎをしない選択も大事
- バックエンド DB は他と同じ
- 基盤パッケージなどの資産を有効に活用すべき
- 節度ある可用性施策を用いること
- 多用することによって，運用の複雑さが増すだけで，本当に必要な可用性がなくなる可能性も
- 大(やりすぎ)は小(なにもしない)を「兼ねない」
##システム拡張設計のポイント
- 要因
- アクセス増加に伴うもの
- サービス・機能の追加によるもの
- 方針
- 台数を増やすという，スケールアウト
- 性能を上げる・追加するという，スケールアップ
- 別システム・新システムの追加
- 考慮すべき事項
- 仮想化，省エネ・スペース
###サーバのトレンド
- CPU がマルチコア構成になってきたので，少ない台数で多くの CPU を使うことができる．
- RAS 機能の向上
- サービスプロセッサによる監視・管理機能
- 活性挿抜
- H/W RAID など
###サーバ構成の変化
- 1サーバで複数の OS インスタンス
- 仮想化
###仮想化のポイント
- OS 仮想化がいいようだ
- それぞれの利点に応じて使い分けが必要
###サーバ集約は必須？
- 省スペース，省消費電力には集約は必須
- 機能面での集約をするか，仮想化により複数の OS インスタンスを1サーバに配するか．
