というわけで、本日は「オープンセミナー2011＠岡山」に参加してきまして、その発表内容のメモをば、下記に。（完コピじゃありませんし、聞き間違いや書き違えがあるかと思います・・・そういった箇所はご指摘頂ければうれしいです！） Twitterのハッシュタグは「#OSO2011」です。
【講師】 株式会社倉敷ケーブルテレビ 技術部次長 小山海平 氏 【概要】 IANAの在庫枯渇、APNICの枯渇が現実となった。枯渇後のxSPの考え方、 アクションプラン、旬な取り組みを紹介します。 << -枯渇の定義もありますが・・・ --2011年1月IANA枯渇 ---枯渇時計が０％に ----Twitterで「枯渇なう」 ----IANAの在庫がなくなった ----枯渇の定義 -----各RIRに/8の配分を行うものを除いた枯渇 ----ラストはハイペースに（駆け込み需要） ---ホッとした人も多数（狼少年と呼ばれてしまってた方々。） --2011年4月にAPNIC枯渇 ---新規割り振りは/22へ ----中国とインドを抱えたアジア（経済成長著しいほどそのスピードも速い） ----新規事業者は優先 ---申請中に枯渇した案件もあり、揉めている ----ただ、いつかは枯渇するので、あまり未練を持っていてもしょうがないでしょ ---RIRによってはスカスカ？ ----たとえば、AfriNIC（やっぱり経済状況に比例する・・・） ----アドレスを売るような事象も出てくるのでは？ -誰の枯渇？ --IANA、RIRの枯渇は直接的には利用者には無関係。 --ISP・IDCの枯渇は？（利用者に直接的に問題になるケース） ---本来は1年後の予測にてIPを割り振りするので、1年以内にみんな枯渇する（しなきゃいけない）はず。 ----でもまぁ、経済状況・サービス状況にも依存するので。。 -----「枯渇するもの」という前提でやっていくべきではないでしょか。 ----PIホルダー・移管の話も。 ----相対売買と移管も無い話ではないが、財務的な処理をどうするかはかなり問題。 -----IPアドレスはISPの資産ではない。管理を任されているだけ。資産売却には相当しない -枯渇後の対応 --在庫のIPv4延命。 ---CGN、LSNの利用 ----ISPが利用するドデカイNAT。プライベートアドレス空間でネットを使えるように ----PIホルダーなどの未利用部分の再利用 --IPv6の実装 ---未対応機器の入れ替えとかコストがかかる。 ----様子見の企業多し ---課題・問題点が多い。 ----IPv4も最初からカンペキだったわけじゃない。使いながらバグフィックスすればいいんじゃない？ブラッシュアップ。 -IPv4の延命 --所有しているIPv4の延命は、有効活用としては正しい。 ---すぐにIPv4不要とはならない。（○） ---延命措置に関わるコストは無視できない（×） ---延命したからv6は不要というわけではない（×） -CGN、LSN --Carrier Grade NAT,Large Scale NAT --課題・問題点 ---昨今の高速通信に対してソフトウェア処理が入る関係で対応できない可能性がある。どうしてもソフトウェア処理が入る。全部をハードウェア処理はできない。 ---ユーザ宅のルータと合わせて多段NATになってしまい、一部アプリケーションが動作しなくなる可能性あり -課題・問題の一例 --セション数の限界 ---ユーザの収容数、TCP・UDPのKeepAliveをどの程度に設定するのかはあるがセション数の限界は必ずある。 ---アプリケーションが高速通信のために、複数の通信を同時に行う。 ----iTunesはセション数250くらい。ニコ動は100くらい。 --ユーザーのトレーサビリティ ---ISPにとっては、不正アクセスや予期しない異常通信対策として、特定通信に大してのトレーサビリティが必要。 ----トレースの元ネタはIPアドレス。 ----ここから、DHCPをたどりユーザー特定。 ----CGN・LSN配下では、この方法ではダメ。 ----NATより上ではポート番号が必要。配下で使用しているプライベートIPアドレスとつきあてる？ -IPv6の実装 --機器の対応状況 ---ISPがバックボーンで使用する機器はほぼ対応済み。 ---CiscoにしてもJuniperにしても、機器の寿命を5年程度としてみれば、OSのVersion等は必要な場合もあるが、対応されているとみていい。 ---サーバー系OSもほぼ対応済み ----ロードバランサ・Firewallは色々・・・ ----コンテンツやログツールなどは未対応も多い -----アドレスを内部で直書きとか・・・ ---クライアントOSも新規購入ではほぼ対応済み。 ----OSはNative IPv6を優先した動作をしてしまう。 ---ラストワンマイル機器 ----最新機種では対応も出てきている・・・が、入れ替えしにくい分野。 ----ただし、セキュリティやマネージメントまで含めると問題・課題はある。 -----不正RA -----リンクローカルアドレス通信のトレーサビリティ -----プロビジョニング ------顧客管理システムと連携している場合がある --やっぱり対応していかなければいけないと、みんなが思い始めている --対応したからには、早くみんなが対応してIPv4の依存度が早く下がった方が、Internet全体でのコストは下がるだろうと思い始めている -World IPv6 Day --ISOCからのアナウンス。 --24時間の時限イベント --Webサイトをv6対応に。 --ワールドワイドでの検証目的。 ---0.05%に問題がでるという世界予測。 ---問題解決方法の模索とv6導入促進。 -IPv4アドレス枯渇対応TF --教育WG、テストベッドWG --v6技術者育成を目的としたハンズオンセミナーを各地方で開催 -最後に --サーバー・アプリケーション技術者のみなさまへ ---いつかは対応が必要なのであれば、速いほうが知見も取得できます。積極的に対応を考えましょう。 --ISP技術者のみなさまへ ---ラストワンマイル機器さえなんとかなれば、対応は目の前です。対応できそうな部分は機器の入れ替え・グレードアップでまめに対応していきましょう。 ---検証環境や教育については是非ご相談下さい。 -質疑応答 --推薦図書は？ ---オライリーのv6エッセンシャルがいいのでは。v6は変化の激しい分野。なかなか出版おいついてない。それを考えるのもTFでの議題。 --v4だと言いやすい語呂があるけど・・・（イチニッパ、とかｗ） ---非常に重要。電話じゃなくてメッセンジャーでやり取りするのはどうでしょう？（笑）いかに分かりやすいアドレスを付けるか？という議論もあがってますね
**CSS Nite in OKAYAMAの紹介
【講師】 （株式会社CODE54 代表取締役 後藤 誠 氏 急病（39度9分の高熱）のためお休み） CSS Nite in OKAYAMA 実行委員会副代表 岡崎理枝子 【概要】 CSS Niteとは／開催のきっかけ、想い／CSS Nite in OKAYAMA開催概要 << -CSS Niteの概要 -目的 --最新の脳初を岡山にいながらにして習得できる機会を提供すること --ノウハウ・知識を共有して情報交換の場を提供すること --岡山におけるコミュニティを形成すること --Web製作者などのスキルアップを図ること -Webディレクション技術について（7月2日開催） --ディレクションといってもいろいろあるが・・・ --PMに近い？ --案件を円滑に進めていくこともさることながら、自分らしく。 --Webディレクターとしての走り方を紹介
【講師】 社団法人システムエンジニアリング岡山 Ruby普及コーディネータ 宇野 寛三 氏 【概要】 岡山県におけるRubyのビジネス活用事例等を紹介します << -SEOとは？ --System Engineering Okayama --他府県では「情報サービス産業協会」と呼ばれている団体。 -プログラミング言語・Rubyとは --日本生まれのオープンソースプログラミング言語 --「まつもとゆきひろ」氏が開発 --インタープリタ方式（コンパイル不必要） --手軽なオブジェクト指向プログラミング --JIS規格にも登録 -Rubyの特徴 --簡潔さ --書きやすさ --生産性 -Rubyの活用展開 --消費者向け：楽天、Twitter、価格.com（食べログ）、クックパッド ---@razon TwitterはJava/Scalaベースにリプレースされましたよー --業務向け：勤怠管理システム、店頭販売サポートシステムなど -岡山県におけるRubyの取り組み --Ruby普及啓発セミナー開催、中高生向けRubyプログラミング入門講座開催、Ruby on Rails勉強会開催 など
岡山のコミュニティ紹介 *Okayama IT Engineers Community -岡山県でIT関連の勉強会開催の促進を行う -取り上げる技術は特に定めない -オフライン重視 -スタッフのつながり的に、MSのテクノロジに寄ってることがおおいかも？ -合同勉強会をやったりすることもあり -7月9日に勉強会開催予定
***岡山WEBクリエイターズ -閉鎖的な勉強会はあるんだけど・・・というような状況を打破すべく -2ヶ月に1度 勉強会 -デザイナー、ディレクター、コーダー、エンジニア -WEBの「今」を本気で学びたい、最新技術からトレンドまで -交流会の役目も -サーバー裏事情、jQuery、フリーランスについて・・・など幅広い話題 -敷居は低く入りやすい内容を目指している -mixiのコミュニティもあり -岡山のWeb業界を盛り上げていきましょう！
***岡山Ruby,Ruby on Rails勉強会 -Ruby,Ruby on Railsについての勉強会を開催している、現在までに8回ほど -2010年2月に発足 -2ヶ月に1度程度 -岡山県南部のどこかでやってます -Ruby関連での話題提供 --iPhone向けのシステムづくりについて --サーバーへのデプロイ方法について -様々な勉強会が派生してます --初心者向けハンズオン --Rails潜水部 -参加するには？ --「岡山 Ruby」で検索、MLに参加すれば勉強会情報をお届け
***X-lab -関係者の方がお休み・・・ -Webページで詳細を見ることができる
***すくすくスクラム瀬戸内 -すくすくスクラム瀬戸内って？ --アジャイル開発手法のひとつ「Scrum」を中心とした現場改善の手法をみんなで学んでいくための勉強会 -どんなことしているの？ --ソフトウェア開発現場の課題認識・提起 --カラダで覚えるスクラム --ふりかえりワークショップ -傾向 --人間系の話が多いです -今後 --テスト駆動開発に力を入れたい --技術系のコミュニティと共同開催できるとうれしいです
***中国GTUG -about --2,3ヶ月に一回、中国地方のどこかで、google技術を使って楽しむgoogle公認のユーザー会 --メンバー31名 --発表してほしいテーマリクエスト募集中 --講師も募集中 --スタッフもそろそろ・・・ -GTUG？ --google技術を扱うユーザ会 --レクチャー、デモ、ハンズオン、ハッカソン --日本には６つ -メンバになるには？ --google groupへの登録 --興味あるgoogle技術を回答してください。
***天領倉敷Scala -Scalaってなに？ --JVM上で動作する --オブジェクト指向と関数型プログラミングのハイブリッド -マスコット駆動開発ｗ --@scalachan をフォローしてね！！ -何も考えずにMLに登録！ -他の勉強会との交流（妨害？） -（オープンラボ備後がLTハック）
***日本Androidの会 -「続きはWebで」じゃなくて、最初からWebで。 -詳しくもWeb見てね！
***OSC -オープンソースカンファレンス広島 -目的 --オープンソースコミュニティの活動成果の発表の場を提供 --開発者とユーザとの出会いの場 -MLに登録するだけ！
**JavaSE7で切り開く新しいJavaの世界について
【講師】 日本オラクル株式会社 シニア Java エバンジェリスト 寺田 佳央 氏 (http://yoshio3.com) 【概要】 2006 年 Java SE 6 が登場し５年が経過し、今夏ついに待望のJava の新バージョン Java SE 7 がリリースされます。本セッションでは Java SE 7 で提供される新機能や言語仕様の変更点等を分かり易く紹介します。 << -はじめに --自己紹介 --Oracleは今後も積極的にJavaに投資します。 --Sunの頃よりもJavaに対する本気度があがったと感じている -Java7について --ごにょごにょ -プロジェクトCoin --言語仕様に関する小さな改良 ---switch構文における文字列の使用 ---数値表現形式の追加 ----バイナリ表記 ----アンダースコア表記 -----数値表現中にアンスコを記載することで意味ある単位に分割可能（可読性の向上を目的、クレカの番号とか。）単なる表現、内部でreplaceAllしてる ---マルチキャッチ ----一行のcatchで複数の例外をcatchできるように！ ---try内で例外の再送が可能に ----finalつける ---Genericsインスタンス生成における型推論の改善 ----「<>」（ダイアモンド）で済むんですよ〜（Rubyに掛けて・・・ｗ） ---リソースを含むtry構文 ----tryでCloseableインタフェースの実装クラスを ----finalyでclose処理が不要、自動的にリソースのclose()が実行 -Java NIO.2 --More New IO APIs for the Java Platform --ファイル操作などがすごくラクに、パフォーマンスも大幅改善 ---ファイルシステム用のAPIを提供 ---シンボリックリンクをサポート ---非同期I/Oサポート ---zipをファイルシステムとして処理可能 など --ファイルシステムAPI ---主要パッケージ ---FileSystemクラス ---Pathインタフェース ----PathsクラスからPathインスタンスを生成できる ----ドット表記の削除（path.normalize()で自動的に。ファイルの存在チェックまではしてないので注意。その場合はpath.toRealPath(true)で！） ----相対パスの取得（path.relativize()） ---ファイル操作用API ----クラス中のメソッドは全てstaticメソッド ----使用例 -----ディレクトリの作成 -----追加書き込みモードでオープン -----ファイルのコピー（copyメソッドを用意） -----シンボリックリンクの作成 -----ディレクトリツリーの走査 -----ファイルシステムの変更通知 -----ストレージ情報の取得 -Da Vinci Machine Project --他の動的言語をサポートするために追加されたもの！ --今までのJavaプラットフォームは・・・ ---言語＋API＋VM だったよね --今後は？ ---マルチ言語プラットフォームに。Java言語以外で実装されたアプリの動作も可能に！ --InvokeDynamicバイトコード命令の追加 --バイトコードで表されていれば、それがJavaでコンパイルされたものでなくても動く！ --JavaVMがより柔軟なメソッド呼び出しを可能にし動的言語をより動作させやすくする命令 --動的言語の開発者はメソッドに含まれるターゲットタイプを指定せず、メソッド呼び出しをバイトコードに記述することが可能 -Concurrency Util --1.4まででは、並列処理の（正しい）実装は困難 --並列処理の実装を容易に ---CPU数を取得しスレッド数を決定できる（CPU分のスレッドプールを生成できる！） --Fork/Join FWの概念 ---大きな問題を細かい問題に分割し、解決したあとマージし結果を得るという考え方 ---並列化の閾値の設定はぜひ試行錯誤してください（並列化のオーバーヘッドが大きくなるので） -国際化関連 --Unicode 6.0のサポート ---日本の携帯電話の絵文字とか。 --通貨コードの拡張をサポート --LocalのCategory列挙型の追加 --正規表現でUnicodeのポイントを検索可能 --クラスローダの機能拡張 ---バグの解消（特定のカスタムクラスローダにおいてデッドロックが発生 Bug ID：4670071） -ネットワークプロトコルの拡張 --SCTP ---com.sun.nio.sctpパッケージ ---JavaSEの通常パッケージには含まれない！ --SDP ---ハイパフォーマンスコンピューティング環境用 ---Solaris・Linux環境でサポート -まとめ --JavaSE7の新機能概要 --JavaSEの今後 ---JavaSE7,そして8の公開 --HotSpotVM、JRockit VMについて ---どちらも無償で利用することができるようになります ---いずれの開発も継続します -質疑応答 --暗号化zipは？ ---TLS1.2、ECCに対応 --Da Vinci MachineとAndroidとの関係 ---法的な問題もあり。現時点でお話できる立場にはないんです・・・。。 --ファイルシステム関連が多いということでIDE関連のスピードアップは望める？ ---バージョンあげるだけじゃだめ、そういうコードをかかないと。（そういうコードでIDEを作らないと。） --DBコネクションにもCloseableインタフェースは有効？ ---使えます。 --JavaDocの日本語化のスピードアップをお願いできませんか・・・ ---SE7のドキュメントの日本語化のリクエストは強くお願いしている。
**多言語パラダイムを前提とした設計手法
【講師】 日本マイクロソフト株式会社 エバンジェリスト 荒井 省三 氏（http://blogs.msdn.com/b/shozoa/） 【概要】 メニーコアやクラウド・コンピューティングが台頭してきているように、新しいコンピューティング・インフラが身近になっています。このようなインフラを有効活用しようとすると、今までの設計手法を考え直す必要がでてきます。適材適所という言葉がありますが、システム構築において本当に適材適所を実践できているかと言えば、？が付くことでしょう。 システム構築における適材適所を実践するには、幅広い知識や経験だけでなく、参加するメンバーの意欲なども重要な要素です。適材適所を実践するために、動的言語や関数型言語の組み合わせ方を含めて、開発手法の進化の方向性などを説明します。 << -分析・設計技術 --メンタルモデル ---アレグザンダー ----自然に潜む秩序の性質を捉える ----パターン言語へ ---ダイナブック構想 ----人の支援 ---オブジェクト指向の欠点 ----メンタルモデルの欠如（使う人にとって有益か？） ----プログラミング言語はクラスが中心 ---メンタルモデルを重視 ----アジャイル ----適切なコンテキスト --ユビキタス言語（モデル表現） --関心の分離（SoC） ---境界コンテキストでコアドメインとサブドメインに分離する --2種類のオブジェクトを分離 --振る舞いはコンテキストへ --振る舞い（ロール）のマッピング ---メソッドをどうオブジェクトと関連付けるか？ --ユースケースを使った関心の分離 ---ユースケーススライス --Command Query Responsibility Segregation -分析・設計に必要とされる要素技術 --計算モデルの必要性 ---部分障害、分散、並列、非同期、一時的な非一貫性を前提とした、クラウドやマルチコア全体の振る舞いを抽象的にモデル化する基盤が必要＝計算モデル ----@taraijpn プログラミング言語の得手不得手というのは、もとになってる計算モデルの得手不得手。 #OSO2011 ----意味論の明確化と検証＝アーキテクチャの確立 ---歴史は古いが、クラウドやマルチコアで再注目 ----並列・分散への対応が必要＝実行コンテキスト ---ネットワーク遅延問題は解決できてない ----@taraijpn 新しいハードウェア時代に対応した計算モデルを意識しなければいけない。（でも実は本質的な構成とボトルネック要素はあまり変わってない） #OSO2011 ----システムのボトルネックは、普通「CPU＜キャッシュ＜メモリ＜HDD＜回線」 --計算モデルとプログラミング言語 --プログラミングモデルの方向性 ---並列×分散×同時実行×反応（Reactive）（リアクティブプログラミングの代表例は、イベントドリブン） --プログラミング言語の分類 --プログラミング言語の存在意義 ---特定の問題領域⇔対応する言語 --現代の時代背景 ---ムーアの法則 ----メニーコアシフト ----NUMAの台頭 ---出来なかったことへの挑戦 ----ラムダ式のエッセンス ----クロージャー ----集合演算 --善か悪か〜万能論〜 ---汎用言語（GPL）の万能論 ----是か非か ---メジャーな言語が収束したか？ ----多種多様な言語生態系 ----言語同士が切磋琢磨 ---理想と現実 ----答えはあるのか？ --多言語パラダイム＝現実路線 ---適材適所でプログラミング言語を組み合わせる ----目的に応じた使い分け ---現実的か？ ----学習する言語を増やしたくない ----メンテナーが不在になる ----新しいことを覚えたくない ---トレードオフ ----必要とする機能と工数の駆け引き -ダックタイプ論 --DIコンテナーを提案する理由 ---静的プログラミング言語で、DIコンテナーがよく使われている ---動的言語でDIコンテナが使われていない ----オブジェクト間の結合度がゆるい ----変更が容易 ----静的プログラミング言語の問題点が問題にならない --DIコンテナは使用するメリット ---オブジェクト間の結合度をゆるくする ----契約による設計 ---オブジェクトの入れ替えを容易にする ----モックオブジェクト ----テスト容易性 ---依存性の注入 --DIコンテナを使用するハードル ---コンテナの作成にかかる工数 --オブジェクトを疎結合にする ---名前や引数という契約だけにする ----gynamicキーワードで実現できる ---メリット ----動的にオブジェクトを入れ替えられる（ビルドいらず） ----オブジェクト生成の戦略をスクリプト内にカプセル化 -----スクリプトクラス、初期化、メソッドアスペクトetc -非同期プログラミングの課題 --非同期パターンの複雑さ ---@taraijpn 非同期パターンの複雑さ： begin-endの組み合わせは逐次処理のようになり複雑化する。 #OSO2011 ---より複雑化していく ---スレッドの同期化が難しい --次のVSで新しい非同期FWが導入予定（Async CTP） --Async CTPの特徴 -まとめ --設計手法に答えはない --そのかわり、いろんなコトにアンテナ張ってください --自分の作ったものに対しての振り返りをして下さい --多言語パラダイムとは、適材適所でプログラミング言語を組み合わせる ---言語の特徴を理解 ---適用できるパラダイムを分析する
**App Engine - Google I/Oの果実
【講師】 グーグル株式会社 DeveloperAdvocate 松尾 貴史 氏 【概要】 App Engine もリリースされてから 3 年になりました。これまで様々な機能がコンスタントにリリースされてきましたが、中でもGoogle I/O の時期は沢山の機能がリリースされます。今年も例外ではありません。それら新しい機能の中から幾つかを選んで解説します。 << -Google I/Oでのアップデート内容を報告。 -自己紹介 --PythonとGAEスキスキ -App Engineの歴史 --2008年にデビュー ---無料クォータ内であれば永遠に無料。 ---なんといっても自動スケールするのが特徴 ---ストレージレイヤにdatastore --2009年にプラットフォームの拡大 ---Javaサポート --2010年にいくつかの制限を緩和 --そして2011年。エンタープライズ開発にも使っていって欲しい ---High-Replication Datastore ----従来のマスタ・スレーブ方式と違い、リリース後の稼働率、ほぼ１００％ --2010年5月10日 ---SDK-1.5.0 ---Backends ---Pull Queue with REST API ----外部のシステムからタスクを引っ張ってくることができる ---High-Replication Datastoreがデフォルトに ----マスタ・スレーブ方式は選べるけどあまりオススメしない --AppEngineのパートナー ---アメリカ ----BuddyPoke ----TweetDeck ----DirecTV ----Gigya ---日本でも ----mixiアプリ ----毎日新聞・メディア配信サービス ----ソニー・Chan-Toru --AppEngineの成長 ---1日あたり15億PV ---RoyalWeddingの公式サイトもAppEngineで稼働 ----32000Req/s ----3770万PV ----1370万ビジター ----このために特別にAppEngineクラスタを用意したわけではないのがすごくないですか？？ -Preview卒業について --Preview卒業とは？ ---正式なGoogleのサービスに ----廃止予定になった機能がでたとしても、3年間サポート ---課金ユーザへの99.95%のSLA ---運用サポート、開発サポートの提供 ---ビジネスに適した利用規約 ---請求書ベースでのお支払い ---Frontends,Backends ---新しい、継続可能な料金体系 ----多くのユーザの場合、値上げになると思われる --SLAは単なる数字ではありません --新しい課金体系の概要 ---ユーザーのタイプを3つに分ける ----無料アプリ（クォータがだいぶ下がると思われる） ----有料アプリ（アプリ毎に月額$9（＋利用分）でSLAを含む） ----プレミアムアカウント（アカウント毎に$500、SLAと運用サポートを含む） ---CPU時間に対する課金の廃止 ----動作しているFrontendとBackendの数とサイズ（CPUとメモリ）に応じて課金 --AppEngine for Businessの今後 ---今後なくなります ---Businessで提供しようとしてた機能がAppEngine本体に吸収されるイメージ。AppEngine一本で！ --つまり卒業はお客様にとって何を意味するか ---Googleは今後もAppEngineをサポートすると宣言したと同義 ----@taraijpn GAEはPreviewから正式なサービスになる、ということで、他サービスと比較しやすいようにしたり、会計まわりの話を整理したり、いろいろ整理するよ、と。 #OSO2011 ---Waveのようにならないように・・・ｗ -AppEngine Backends --AppEngineの哲学 ---AppEngineの目標は、新しいWebアプリケーションを簡単に始められると同時にスケーラビリティを得られる環境を提供すること ---つまり、デプロイが簡単だったり自動スケーリングだったりAPIが豊富だったり。 ---AppEngine流 ----大きな問題を小さな問題に分割（パラレル） ----失敗したらリトライ（必ず失敗するものと思って作る！） ----Horizontal Scaling（スケールアップじゃなくてね） ----Web（http）でのサービス ---全てがWebアプリケーションであるわけではない ----コマンド、レポート生成、グローバルカウンター ---軽量インスタンス ----少量のメモリ ----それほど強力ではないCPU ----指定してアクセスできない（次も同じインスタンスで処理されるとは限らない） ---実行環境の制限 ----30秒の制限時間 --AppEngine Backendsリリース ---AppEngineのインスタンスに加えて ----基本的には今までのインスタンスと同じだが・・・（サンドボックスで動く） ----長く動作し続けられる ----高性能 ----設定可能（メモリ、CPU（スケーリングの方法をダイナミックにするのか常駐的にするのか）） ----指定してアクセス可能（インスタンスひとつに対してURLが割り当てられる） ----永続的（クラッシュしても自動で再起動） ----クラウド上のプロセス ---パワフルな部品 --Backends：AppEngine++ ---メモリは128MB〜1GB ---CPUは600MHz〜4.8GHz ---制限時間なし ---AppEngine流！ ----設定簡単、素早くデプロイ！ --AppEngineは今や ---汎用的なクラウドコンピューティングプラットフォームになった --ユースケース ---メモリが必要なこと ----検索用インデックス ----ソーシャルグラフ ----ゲーム状態 ----メモリキャッシュ ---CPUパワーが必要なこと ----画像操作 ----音声・動画のエンコーディング ----ゲームエンジン ---バックグラウンドプロセス ----data pipeline ----data groomer ----webクラウラー ----taskの実行 -----今までは細切れにしてたけど、Backendsになげるなら不要 ---コマンド、スクリプト ----コマンド叩けば通信するように・・というようなことも可能 ----アドホックなクエリ ----ロードテスト --BackendsのHello World ---yaml、xmlに定義を記述 ---5つまで設定可能 ---ハンドラーの定義はアプリケーション、backendで共通 ---アプリケーションのコード自体も共有 ---Backendsは一度にひとつのリクエストしか処理できない。 ----もうひとつはpending Queueに入る。 --Backendsの制限 ---アプリケーションごとに5つまで ---アプリケーションごとに10GBまでのメモリ ---backendごとに20インスタンス --注意点 ---APIの制限時間は依然として適用される ----urlfetch、デフォルト5秒まで ----datastoreAPI30秒 ---アップタイムの保証はない ----ベストエフォートのサービス ----2種類のシャットダウンが発生する可能性あり --Backendsの今後 ---スケーリングの改善 ---APIとの親和性 など --BackendsでAppEngineは生まれ変わります --その他の果実 ---Backendsの登場でいろんなユースケースに対応できるようになったと思います。 -質疑応答 --リトライするような作り、といっていたが、監視する方法がなかったと思う。商業利用のことを考えると・・・。 ---おっしゃる通りです。現在、Monitoring APIというものを作成中。 --他の言語のサポート予定は？ ---あります。たとえば、5月10日にはGo言語をサポートするようになりました。 --なんでJavaがPythonに比べて遅い？ ---最初のスピンアップに時間がかかっているためだと思う。工夫としてはstatic変数にウェイクアップ済みかどうかをもたせ、最初のリクエストはすぐに返すとか、段階的なスタートをするようにするなどの工夫をしてる人はいる。緩和する方法としては（Warmupリクエスト？Concurrentリクエスト？）ひとつのインスタンスのスループットを上げる。一回動いてしまえばJavaもそれなりに速いはず。always on、常時3つインスタンスをあげておく機能があるのでそれを有効活用するとか。 --起動時に全てのインスタンスをあげるような仕組みは？ ---AppEngineではLazyLoadの考え方。
ふぅ。 GAEの課金体系、随分変わるんですね〜。今公開してるアプリも、ちょっと考えないといけないかもなぁ。（リニューアルしたいところもあるし・・・）
