えいのうにっき

むかしのじぶんのために書いています

オープンセミナー2011@岡山 発表内容メモ。

というわけで、本日は「オープンセミナー2011@岡山」に参加してきまして、その発表内容のメモをば、下記に。(完コピじゃありませんし、聞き間違いや書き違えがあるかと思います・・・そういった箇所はご指摘頂ければうれしいです!)
Twitterハッシュタグは「#OSO2011」です。



IPv4枯渇後に向けてのISPの取り組み

【講師】
株式会社倉敷ケーブルテレビ 技術部次長
小山海平 氏
【概要】
IANAの在庫枯渇、APNICの枯渇が現実となった。枯渇後のxSPの考え方、
アクションプラン、旬な取り組みを紹介します。

  • 枯渇の定義もありますが・・・
    • 2011年1月IANA枯渇
      • 枯渇時計が0%に
        • Twitterで「枯渇なう」
        • IANAの在庫がなくなった
        • 枯渇の定義
          • 各RIRに/8の配分を行うものを除いた枯渇
        • ラストはハイペースに(駆け込み需要)
      • ホッとした人も多数(狼少年と呼ばれてしまってた方々。)
    • 2011年4月にAPNIC枯渇
      • 新規割り振りは/22へ
        • 中国とインドを抱えたアジア(経済成長著しいほどそのスピードも速い)
        • 新規事業者は優先
      • 申請中に枯渇した案件もあり、揉めている
        • ただ、いつかは枯渇するので、あまり未練を持っていてもしょうがないでしょ
      • RIRによってはスカスカ?
        • たとえば、AfriNIC(やっぱり経済状況に比例する・・・)
        • アドレスを売るような事象も出てくるのでは?
  • 誰の枯渇?
    • IANA、RIRの枯渇は直接的には利用者には無関係。
    • ISPIDCの枯渇は?(利用者に直接的に問題になるケース)
      • 本来は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になってしまい、一部アプリケーションが動作しなくなる可能性あり
  • 課題・問題の一例
    • セション数の限界
      • ユーザの収容数、TCPUDPの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だと言いやすい語呂があるけど・・・(イチニッパ、とかw)
      • 非常に重要。電話じゃなくてメッセンジャーでやり取りするのはどうでしょう?(笑)いかに分かりやすいアドレスを付けるか?という議論もあがってますね

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普及コーディネータ
宇野 寛三 氏
【概要】
岡山県におけるRubyのビジネス活用事例等を紹介します

岡山のコミュニティ紹介

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技術を扱うユーザ会
    • レクチャー、デモ、ハンズオン、ハッカソン
    • 日本には6つ
  • メンバになるには?
    • google groupへの登録
    • 興味あるgoogle技術を回答してください。
天領倉敷Scala
  • Scalaってなに?
  • マスコット駆動開発w
    • @scalachan をフォローしてね!!
  • 何も考えずにMLに登録!
  • 他の勉強会との交流(妨害?)
  • (オープンラボ備後がLTハック)
日本Androidの会
  • 「続きはWebで」じゃなくて、最初からWebで。
  • 詳しくもWeb見てね!
OSC

JavaSE7で切り開く新しいJavaの世界について

【講師】
日本オラクル株式会社
シニア Java エバンジェリスト
寺田 佳央 氏 (http://yoshio3.com)
【概要】
2006 年 Java SE 6 が登場し5年が経過し、今夏ついに待望のJava の新バージョン Java SE 7 がリリースされます。本セッションでは Java SE 7 で提供される新機能や言語仕様の変更点等を分かり易く紹介します。

  • はじめに
    • 自己紹介
    • Oracleは今後も積極的にJavaに投資します。
    • Sunの頃よりもJavaに対する本気度があがったと感じている
  • Java7について
    • ごにょごにょ
  • プロジェクトCoin
    • 言語仕様に関する小さな改良
      • switch構文における文字列の使用
      • 数値表現形式の追加
        • バイナリ表記
        • アンダースコア表記
          • 数値表現中にアンスコを記載することで意味ある単位に分割可能(可読性の向上を目的、クレカの番号とか。)単なる表現、内部でreplaceAllしてる
      • マルチキャッチ
        • 一行のcatchで複数の例外をcatchできるように!
      • try内で例外の再送が可能に
        • finalつける
      • Genericsインスタンス生成における型推論の改善
        • 「<>」(ダイアモンド)で済むんですよ〜(Rubyに掛けて・・・w)
      • リソースを含むtry構文
        • tryでCloseableインタフェースの実装クラスを
        • finalyでclose処理が不要、自動的にリソースのclose()が実行
  • Java NIO.2
  • Da Vinci Machine Project
  • 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
      • ハイパフォーマンスコンピューティング環境用
      • SolarisLinux環境でサポート
  • まとめ
    • 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/
【概要】
メニーコアやクラウド・コンピューティングが台頭してきているように、新しいコンピューティング・インフラが身近になっています。このようなインフラを有効活用しようとすると、今までの設計手法を考え直す必要がでてきます。適材適所という言葉がありますが、システム構築において本当に適材適所を実践できているかと言えば、?が付くことでしょう。
システム構築における適材適所を実践するには、幅広い知識や経験だけでなく、参加するメンバーの意欲なども重要な要素です。適材適所を実践するために、動的言語関数型言語の組み合わせ方を含めて、開発手法の進化の方向性などを説明します。

App Engine - Google I/Oの果実

【講師】
グーグル株式会社
DeveloperAdvocate
松尾 貴史 氏
【概要】
App Engine もリリースされてから 3 年になりました。これまで様々な機能がコンスタントにリリースされてきましたが、中でもGoogle I/O の時期は沢山の機能がリリースされます。今年も例外ではありません。それら新しい機能の中から幾つかを選んで解説します。

  • Google I/Oでのアップデート内容を報告。
  • 自己紹介
  • App Engineの歴史
    • 2008年にデビュー
      • 無料クォータ内であれば永遠に無料。
      • なんといっても自動スケールするのが特徴
      • ストレージレイヤにdatastore
    • 2009年にプラットフォームの拡大
    • 2010年にいくつかの制限を緩和
    • そして2011年。エンタープライズ開発にも使っていって欲しい
      • High-Replication Datastore
        • 従来のマスタ・スレーブ方式と違い、リリース後の稼働率、ほぼ100%
    • 2010年5月10日
      • SDK-1.5.0
      • Backends
      • Pull Queue with REST API
        • 外部のシステムからタスクを引っ張ってくることができる
      • High-Replication Datastoreがデフォルトに
        • マスタ・スレーブ方式は選べるけどあまりオススメしない
    • AppEngineのパートナー
    • 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一本で!
    • つまり卒業はお客様にとって何を意味するか
  • 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
      • yamlxmlに定義を記述
      • 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言語をサポートするようになりました。
    • なんでJavaPythonに比べて遅い?
      • 最初のスピンアップに時間がかかっているためだと思う。工夫としてはstatic変数にウェイクアップ済みかどうかをもたせ、最初のリクエストはすぐに返すとか、段階的なスタートをするようにするなどの工夫をしてる人はいる。緩和する方法としては(Warmupリクエスト?Concurrentリクエスト?)ひとつのインスタンススループットを上げる。一回動いてしまえばJavaもそれなりに速いはず。always on、常時3つインスタンスをあげておく機能があるのでそれを有効活用するとか。
    • 起動時に全てのインスタンスをあげるような仕組みは?
      • AppEngineではLazyLoadの考え方。

ふぅ。
GAEの課金体系、随分変わるんですね〜。今公開してるアプリも、ちょっと考えないといけないかもなぁ。(リニューアルしたいところもあるし・・・)