radioc@?

レディオキャットハテナ

【勉強会メモ】【大阪】LINE Developer Meetup #31

Java Kotlin Android iOS 勉強会

line.connpass.com

  • 日時：2018/03/30(金) 18:30 〜 21:30
  • 場所：TKPガーデンシティ大阪梅田

京都に新オフィスを設立予定のLINEの勉強会。今回は大阪で開催されました。

Javaとモバイル

Javaは古くからモバイルアプリの開発に使われてきた言語ですが、その変遷は意外と奥深く、色々な背景があったりします。断面的にはスポットが当たることがあっても時系列に並べてまとめられる機会は意外と少ないので新鮮でした。懇親会でも改めて経緯を知れるのは良い機会だったという話を参加者同士でしました。

Metal Framework

Apple独自のグラフィックAPIの話でした。古くからOpenGLが使われてきましたがMetalはApple専用に開発されたことで処理速度やメモリ共有の面で使いやすく高パフォーマンスが実現できるということのようです。残念ながらこの分野はあまり詳しくないので多くは語れません。

KotlinでDSL

Kotlinで手軽にDSLを扱うことができて、従来のUI周りのXMLで書く部分をコーディングしやすく可読性を高める手法がデモを交えて紹介されました。コードと一緒に扱うことで交互に背景色を変えるなどの動的な制御もリーダブルかつ簡単に実現できます。XMLがカオスになる危険を回避できるかわりにUIのコードがビジネスロジックと混ざってカオスになる危険は出てきそうなので、そのあたりをうまく設計する必要はありそうだと感じました。

New Java Things Mobile Developer Should Know

LINE Fukuoka: きしだ なおきさん

Javaとモバイル

1992 Green Project CPUやOSに依存しない

  • 1999 Java ME
  • CLDC…携帯電話やディスプレイを持たないデバイス向け
  • MIDP…EZアプリ、S!アプリ
  • Doja…iアプリ
  • CDC…Blu-rayプレイヤーなどのディスプレイにつなぐデバイス向け

↑ここまでけっこう安定していた

Java SE8 Compact Profile

JavaSE自体がモバイルで使えるようになった

Compact Profile 1〜3、Full Profile

Java9

  • Javaモジュール化
  • 必要なモジュールだけで実行環境が作れる
  • Java 8のCompact Profileもモジュール化の途中成果物

リリースサイクルの変更

  • 毎年3月と9月（秋分の日と春分の日の前後）
  • パッチなどの提供は次のリリースまで
  • 3年ごとにLTS

Java10

  • 2018年3月
  • ローカル変数型推論
    • var strs = List.of("aa", "bb")
  • Dockerへの対応
  • GCのモジュール化

Java11

  • 2018年9月
  • Oracle JDKとOpenJDKは同一バイナリになる
  • Oracle JDKは無償提供されなくなる
  • JavaFXはJDKにバンドルされなくなる
  • HTTP Client API
  • switch式(?)

半年単位でJavaの言語仕様もかわっていく

Javaのモバイル対応への私感

  • モバイル専用プラットフォームの必要性が薄れている
    • モジュール化
    • デバイス性能の進化

モバイル用の実行環境が必要なくなる

AndroidとJava

Apache Harmony

Androidとは

Harmonyの挫折

Dalvik VM

  • レジスタマシンベースのVM
  • devファイルを実行
  • javac->dx

Android Runtime(ART)への移行

  • 2014年
  • Dalvik VMは少ないメモリやシングルコア向きだった
  • AoT(Ahead of Time)コンパイラ
    • dexファイルをネイティブ実行ファイルに事前コンパイル

ライブラリをOpenJDKに

  • 2011年Harmonyプロジェクト終了
  • 2016年Androidの標準ライブラリをOpenJDKに変更することを発表
  • Java 8 Date Time APIなど導入

Java8の言語仕様を導入

  • 2014年Jackツールチェーンの発表
  • jack
  • 2017年Jackツールチェーン廃止
    • 既存.classツールが利用できない
  • desugar
    • javac->desugar->dx

Ocaleの訴訟

Javaのモバイル実行環境

Javaのモバイルフレームワーク

まとめ

Lets have a look at Apple's Metal Framework

LINE Kyoto: Freddy Vogelさん

英語だったのと元々あまり詳しくない分野の話のため詳しいメモはありません。話を聞きながら参考にしたサイトをいくつか載せておきます。

Metal

Apple's Metal Framework

History

※参考

engineering.linecorp.com

qiita.com

Create your DSL with Kotlin

LINE Kyoto: Freddie Wangさん

※こちらも英語だったので詳しいメモはありませんがデモアプリの説明が中心でした。

What's DSL

  • Improve
  • Flexible design
  • Code readability

SQL, Gradle, Regular Expression

Kotlin DSL in real world

Main features in Kotlin

デモ用アプリ

github.com

まとめ

  • Very easy to create custom DSL with Kotlin
  • We can use DSL to write readable , maintainable code very easy

【勉強会メモ】【Scrum Inc.+KDDI/ESM】Scrum勉強会 in 大阪

勉強会 アジャイル開発 Scrum

esminc.doorkeeper.jp

  • 日時：2018-03-27（火）15:00 - 18:00
  • 場所：KDDI大阪ビル 1階 大会議室

業務提携したということで先日ニュースになっていましたが、KDDIと米Scrum主催の勉強会に参加してきました。

cloud.watch.impress.co.jp

特に印象に残った言葉をいくつかピックアップします。

都合のよいところだけ取り入れるな

スクラムの一部のエッセンスを取り入れてみるというのはよくあるやり方ですが、実際のところそれは元々の開発プロセスの一部をカスタマイズしたにすぎないと思います。たとえ上手くいったとしてもそれはスクラムだからではないということだと思います。

また、スクラムのフレームワークはシンプルであるがゆえに定義されていない部分は自分たちでやり方を考えて進める必要があります。しかし最低限定義されたフレームワークの本質を正しく理解していないと、自分たちでやり方を考えるうちに本来守らなければならないシンプルなルールでさえ崩してしまう危険があると感じています。

チームを維持することによってプロダクトの予測は立てやすくなる

スクラムで開発するとリリースまでのスケジュールがわからないという不安は私の経験でもありました。しかしスクラムに慣れたチームは作るものさえ決まればストーリーポイントで見積もることができて過去のベロシティからスケジュールの予測は立てられます。予測を立てやすくするのであればチームを維持したほうが良いというのはスクラムを経験したおかげで理解できました。

彼らが嫌いなのはアジャイルではなく変化

スクラムを広めていこうとした時に様々な障壁があると思いますが、たとえ否定的な反応があったとしてもスクラムを否定しているのではないということは意識したいと思いました。今までのやり方を変えるということは誰しも不安があるものなので、変化に対して安心感が得られるようにすり合わせをしながら広げていくことが大事なのだと思いました。

真のScrumの導入

Scrum Inc. 副社長 Avi Schneier氏

※遅れて出席したため途中からのメモです

強い会社を作る6つの特徴

  1. 不安定さが組み込まれている
  2. プロダクトチームの自己組織化
  3. 開発フェーズのオーバーラップ
  4. マルチラーニング
  5. 最小限の管理
  6. 組織間の学習

ひとつでも欠けていてはだめ

スクラム

アジャイル視点からのリーン生産のための軽量フレームワーク

スクラム導入事例

北米トヨタの事例

小規模開発チーム

  • Scrumの必要性をA3の資料で経営層に説明
    • マネジメントが協力してくれなければ彼らがチームを壊してしまうため
  • 次にチームを説得
  • コーチを派遣
    • コーチは選手の後ろで観察をしてチームがうまくいくのを手助けする

⇒3ヶ月間は準備期間、6ヶ月間にベロシティは2倍

  • 一つのチームに浸透させて拡大する
  • Scrumの手法を完全に採用する
    • 都合のよいところだけ取り入れるな

4年間でプロジェクト完了数が0.6から2.0になった

大規模金融機関

  • 〜45,000名のメンバー
  • 60%外注

スクラムをやった結果

  • 海外に外注はよくない、スピードが上がらない
  • 縦割りを壊してクロスファンクショナルなチームにする
  • 職能横断チームにすると速い
  • 外注を1/3にした

Scrumの導入により、KDDIがどう変わったか？

KDDI 和田 圭介氏

2013年 市場の変化スピードが急激に上昇

グローバルの開発トレンドを調査⇒多くの企業でアジャイル開発が採用されていた

  • 企画・開発チームの一体化（Scrumの導入）
  • 開発の内製化
  • パートナーとは準委任契約&チームとして働く
    • パートナー社員＝成果物責任を負わない
  • 2人ぐらい社員、3人ぐらいがパートナー

Scrumチームを少しずつ増やす

企画部門の変化

  • 企画担当からプロダクトオーナーへ
  • 顧客開発モデルを導入し顧客の課題を解決するMVPのリリースを目指す

開発部門の変化

品質保証の変化

  • 各チームにテスターを1名配置
  • スプリント内で開発と受入試験を完了
  • チーム内で自動化する範囲と手動テストの範囲を決める

パートナーとの関係性

  • チームの安定性重視
  • アジャイルで開発ができるパートナーを選定
  • 長期の良好な関係を継続

品質の向上

  • スプリントで発見したバグは即修正
  • 常に自動テストで動作を確認

迅速なリリースとコスト削減の両立を実現

  • 開発期間は当初想定の半分、コスト1/3

アジャイル開発の広がり

  • 15チーム以上、200名体制

KDDIのこれからの取組み

スケールするアジャイル開発

  • 大規模案件の要望やスピードアップ
  • スケールするアジャイル手法の習得・実践

UI/UX

DevOpsの洗練

悩みごと相談会

改善アクションとして見積もり不能なものを取り入れて良いのか

プロセスの改善の場合はチームに求められるものであれば見積もる必要ではない

  • ポイントをつけることができるケース
    • 例）Javaをみんなで勉強する
    • チームのキャパシティからポイントをつけてベロシティに入れる
  • ポイントをつける必要がないケース

ただし、スプリントをまわしているなら実施後に評価できるようにしたほうがよい

⇒ふりかえりで評価する

スクラムマスターをどうやって増やしたのか

KDDIの事例

  • スクラムの経験のない人がSMになる
  • セミナーを実施
  • コーチから助走
  • 社内のコーチを育成中

他の例

  • アメリカでは職場で募集しSMとPOはやりたいと言う人にやってもらう
    • 募集要項にSMとPOに必要な要素を書いてそれにapplyしてもらう
  • 本当にやりたい人にやってもらう

ドキュメントをどの程度残しているか

  • 運用に引き渡す場合はドキュメントを残す
    • 古いWF開発に慣れていて運用できるエンジニアがいない運用部隊がある
    • ただし要求仕様書のようなドキュメントの量は減った
  • AWSエンジニアのような会社に引き渡す場合
    • 一緒にチームに入ってもらって引き渡すためあまりドキュメントは作らない
  • 設計仕様書
    • 会社的にSMやエンジニアが急に異動することもあるためConfluenceに残す

どのタイミングで作るか

  • スプリントの中でテストまでやっているので最低の設計情報は残す
  • 次のスプリントで仕様が変わるなら変更する

チームによりけり

  • 他チームとの連携の境界線がREST API⇒境界線の部分は残す
  • 運用への引き渡し⇒重ために残す

プロダクトの見積もりが乖離しないのか

プロジェクトのリスクヘッジの話

  • リスクをどの程度見込んでおくか
  • POと調整をかけながら帳尻をあわせる
  • POと最小セットは何かを考える
  • 開発TとPOが対立しないようにする

しょうがないこと

  • WFとスクラムの一番大きい部分
    • WFは最初に見積もると変わらない
    • スクラムは最初に見積もるのは同じだが見積もりをどんどん続ける
    • WFの見積もりはほとんど当たらない
    • スクラムは最初の見積もりが間違っていても構わない
    • 続けることによってより良くなっていく

初期の見積もりはポイントを付けるが外れることは多い

  • バーンダウンチャートを付けて進めながらリリース時期を見極める
  • チームを維持することによってプロダクトが変わっても予測が立てやすくなる
  • 新しいチームはベロシティの予測がしにくい

WFに慣れた人がスプリントをくりかえす中で何度もテストすることに抵抗感

  • 新しくやる人には抵抗感がある
  • 後ろ向きな人がいるのも確か
  • 前向きな人をみつけてうまくやって広げていく

顧客からはWF方式で多くのドキュメントの納品を求められる

表向きはWFのままで進めて実際はスクラムで開発する方式

  • 10年前ぐらいにアメリカでも実際に遭遇したことがある
  • 1〜5枚ぐらいのドキュメントで充分

金融機関は規制が厳しい

  • POは1日の半分をドキュメント作成に費やしていた
  • ドキュメントを統制する人に話をした（POと統制側にミスコミュニケーションがあると考えた）
  • ドキュメントによって本当に知りたいことは何かを聞いた
    • 何の変更をしたか、なぜ変更をしたかがわかればよかった
    • 3行で済んだ
  • ノードキュメントが無理でも顧客の横に座って何が本当に必要かを聞いて彼らがそれに答えてくれればドキュメントを減らすことはできる
  • 彼らが嫌いなのはアジャイルではなく変化

KDDIでも最初は必要なドキュメントが多かった

  • 続けていくうちに必要な文書は減っていく

【読書メモ】イシューからはじめよ

読書 マネジメント ビジネス 知的生産

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

知的生産の名著ということで以前からストックしてたものの、なかなか時間をつくることができず、やっと読むことができました。2010年初版で著者は現ヤフーCSOの安宅氏。

イシューとは本当に解くべき問題のこと。価値のある仕事をしようとした時に、その質を高めることばかりに意識がいきがちだが、そもそもそれが本当に重要な問題なのかを考えることは解の質を高めるためにも重要なことである。本書ではあまり触れられていないが個人的には価値が多様化し変化の激しい現状のビジネス環境ではイシューの見極めの難易度は高まってきているように感じるので、仮説・検証を繰り返す中でもイシューに度々立ち返って問いただしてみることも重要だと感じた。

バリューのある仕事

バリューのある仕事は次の2軸から成り立っている。

  • イシュー度
  • 解の質

筆者はこれらをそれぞれ以下のように定義している。

イシュー度

自分のおかれた局面でこの問題に答えを出す必要性の高さ

解の質

そのイシューに対してどこまで明確に答えを出せているかの度合い

イシュー度と解の質の両方が高いのがバリューのある仕事なので、いくら解の質を高めても元々のイシュー度が低ければバリューのある仕事にはたどり着けない。まずはイシュー度の高い問題に絞り込んで解の質を上げるアプローチによって仕事の生産性を高めることができる。反対にイシュー度が低いままでがむしゃらに解の質ばかりを高めようとするアプローチの場合、仮に仕事に成功してリーダーになっても同じ方法でしか後輩を指導できないため大成することは難しい。筆者はこのアプローチのことを「犬の道」と名付けて踏み込んではならないとしている。

イシューからはじめるアプローチ

イシューから始はじめるアプローチでは以下のような流れでアウトプットする。

  • イシュードリブン
    • 本当に答えを出すべき問題の見極め
  • 仮説ドリブン
    • イシューを分析して小さく分解する
    • アウトプットに向けて分析・設計しストーリーを整理する
  • アウトプットドリブン
    • ストーリーの骨格を整える
  • 論拠と構造を磨いてアウトプットとしてまとめる

イシュードリブン

仮説を立ててイシューを見極める。良いイシューとは以下の条件

  • 本質的な選択肢である
    • 本当に答えをださなければならないイシューであるか？
  • 深い仮説がある
    • 仮説を深いものにするためには常識を否定し、新しい構造で説明できるようにする
    • 新しい構造とは以下の4パターンのような整理方法がある
      • 共通性の発見
      • 関係性の発見
      • グルーピングの発見
      • ルールの発見
  • 答えを出せる
    • 既存の手法で答えが出せるか

仮説ドリブン

イシュー起点で意味のある単位に分解してストーリーを組み立てる。ここでは分解のしかたとしてのMECEやストーリーを組み立てるための分析フレームワークとして3Cや5Forceなどが紹介されている。これらについては様々な書籍などで詳しく解説がされているので割愛。

ストーリーラインとしては以下の2つの型が紹介されている。

  • WHYの並び立て
    • WHYに対して理由や具体例を1つずつ説明していくストーリーの組み立て方
  • 空・雨・傘
    • 「空が曇っているので・雨がふりそう・だから傘を持って出かけよう」というように事実確認・解釈・判断の順に組み立てる手法

shuchi.php.co.jp

ストーリーの骨格ができたら分解した単位のそれぞれをさらに詳細に分析して肉付けしていく。この作業を筆者は「絵コンテ」と名付けている。定量分析の手法として比較・構成・変化の型、分析を裏付ける調査などについて説明されているがこのあたりの分析手法もそれだけをテーマにした解説書がたくさんあるので割愛。

アウトプットドリブン

ストーリーの絵コンテまでが完成したらアウトプットとして整理していく。限られた時間でバリューのあるアウトプットを出すことが重要。

  • 答えありきではない
    • 仮説が正しいという情報ばかりを集めない
  • いくつもの手法をもつ
  • スピードと回転数を重視する
    • 60%から10%完成度を上げるにはそれまでの倍の時間がかかる

メッセージドリブン

最後はメッセージが伝わるように「本質的」「シンプル」の視点で仕上げる。3つの確認プロセスでストーリーラインを磨き込む。

  • 論理構造を確認する
    • 基本構造と前提の確認
  • 流れを磨く
    • 締りの悪い部分や補強不足の確認
  • エレベータテストに備える
    • 端的に説明できるか

【勉強会メモ】関西Javaエンジニアの会(関ジャバ) '18 3月度

勉強会 Java

kanjava.connpass.com

  • 日時：2018/03/20(火) 19:15 〜 21:00
  • サイボウズ株式会社 大阪オフィス

今回の関ジャバはJava EEの動向と来日していたJavaチャンピオンのMarin Thompsonさんの分散システムに関する話でした。Martinさんの話は技術的に高度な話をしていることはわかったんですが、全編英語だったこともあり自分には難しくて説明不能のため割愛します。

JavaEEの動向

さて、問題のJava EEですが、これまで色々あったことを考えると結果的にEclipseファウンデーションへ移管されたことは前進のステップと捉えて良いのではと思います。TomcatをJakartaの時代から使っている身としてはJakarta EEも違和感はありませんし、Java EEを取り上げられたうえでのJakarta EEというのは若干カウンターパンチっぽくて面白いです。MicroProfileやMVCとの住み分けなどまだカオスな状況もありますが前向きに動向を見守りたいところではあります。

Java EEからJakarta EEへ

@jyukutyo さん

Java EEはJakarta EEへ名前が変わった

Java EE

Eclipse ファウンデーション

  • ×Eclipse使わないといけない⇒どんなIDEでも大丈夫
  • 様々なOSSや仕様を管理

プロジェクト名

今後はよりオープンでコミュニティ主導の開発になる

  • 今まではOSSだけどあるだけ
  • プロセスはJCPのまま

プロジェクトを1つ１つEclipse Public License 2.0 にサイレンスし知的財産レビューを実施

  • 移管後は接頭辞Eclipseがつく
    • 移管作業中
  • 互換性テストキット（TCK）もOSSに（今まではNDAが必要）
  • 全ての移管完了まではあと半年以上かかる予定
  • 当面の目標はJava EE8互換のリリース
  • 今後は誰でもJava EEの仕様策定・開発に携われる

開発プロセス

  • EE4Jの新しいプロセスを策定中
  • オープンで柔軟で素早い（nimble）開発プロセス
  • このプロセスでリリースするものがJakarta EE

Jakarta

  • 投票の65％がJakarta
  • かつてApacheファウンデーションがJavaライブラリを開発する際に使っていた名前
    • Apacheに許可を得てJakartaを使用
    • Jakarta EE自体はApacheと関わりはない
    • そもそもなぜJava EEから名前を変えたのか
      • オラクルの商標でありJava EEのままだとオラクルが管理している印象がある
      • 既存のjavax.*パッケージは使えない（新パッケージ未定）

Java EE GUARDIANS

補足：MicroProfile

Java EEをベースに独自仕様も組み込んだマイクロサービス用のフレームワーク仕様

projects.eclipse.org

Jakarta EEとMicroProfileともにEclipse管理だが現状統合予定はない

補足：MVCはどうなった？

MVC1.0が、もうすぐリリース

  • MVC1.0 Java EE 8から落ちる
  • 所有権がオラクルから中心メンバーのIvarさんへ移管
  • Apache License 2.0ライセンスへ
  • JSRのパブリックレビュー投票通過
  • 2018Q2にリリース予定
  • 1.0リリース後、MVC1.0はEclipseファウンデーションへ移管
  • MVCがMicroProfileに入る可能性もある

Cluster Consensus When Aeron Met Raft

Marin Thompson （ @mjpt777 ）さん

github.com

英語力がポンコツなんで全く理解不能でした。分散システムのアーキテクチャに関するわりと深い話をしているようでした。

調べてみると同じテーマで公開している資料があったのでそちらを参照ください。今回の内容は少し構成は変わっているようでした

https://qconlondon.com/system/files/presentation-slides/clusterconsensus-aeron-raft.pdf

【勉強会メモ】Tech Deep Dive #2 in Osaka

勉強会 DB Oracle

techdeepdive.connpass.com

  • 日時：2018/03/17(土) 13:30 〜 17:30
  • 場所：日本オラクル株式会社　西日本支社　関西オフィス

オラクルさんが主催でWebアプリケーションの開発者向けに濃い話をするというテーマの勉強会でした。今回は性能の話が中心でした。

低レイテンシと高可用性

1つめの話はざっくり言うとクラウド時代の性能の考え方の話。Oracle Coherenceはインメモリ分散アーキテクチャによって高速アクセスと高可用性を実現している。

製品情報 - Oracle Coherence

自律型データベース・クラウド

2つめは昨年秋に発表されたOracle Autonomous Data Warehouse Cloudの話。アプリケーション側としてはデータストアやインフラのことは何も考えずに自動で監視・分析したうえでスケーリングや障害の検知・復旧をしてくれるのが理想だよねということで、既にそのような構想が進んでいます。

オラクル、世界初の自律型データベース・クラウドの構想を明らかに | Oracle 日本

近年はOSS中心の生活を送っている自分にとってはOracle製品の目指す世界観が先を行き過ぎていて圧倒される部分はありますが、クラウド時代の性能の考え方についてはおっしゃる通りで、効率よくスケールしたり整合性を維持して早期に障害検知して切り替え・復旧する仕組みはどういう製品や技術を採用するにしても考えなければならず、避けては通れない部分だと感じます。

Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか reloaded

いとうちひろ さん

www.slideshare.net

今日の話のポイント

性能と可用性

性能が悪い製品はクラウド利用のコストが高くなる

性能でよく挙がる要素

↓今後クラウドを使うと重要になる

  • スケールアウト
    • スモールスタートで始めて負荷が上がった時にスケールアウトできないとツライ
  • 効率性

可用性でよく挙がる要素

  • Single Point Of Failure
  • Disaster Recovery

↓今後

  • 即時復旧
    • 止まると影響が大きいサービスも多い
  • 整合性
    • 障害発生直前の状態に戻っていることが期待される

性能と可用性を意識したアーキテクチャの例

  • リージョン内にゾーンが2つ
  • AP Serverは2台で冗長化
    • Data Storeが止まると処理継続困難
  • DData Store は1つStanby
    • 障害で切り替えに時間がかかる
    • 処理能力向上が困難

問題が起きると大変

  • ログを収集
  • 事象の確認
  • 原因の調査
  • 問題の修正

こんなアーキテクチャが欲しい

  • とにかく速い
  • 拡張できる
  • 障害に強い
  • 実装が簡単

↓

  • リージョン複数
  • スタンバイへの切り替えが速い
  • AP Serverもスケールアウト可能

検証で行うデモの負荷パターン

テストケースA

  • 1万件 の商品
  • 徐々にユーザーが増加
  • スケールアウト／アップの効果がある

テストケースB

  • 1件 の商品（1件を取り合いになる）
  • 徐々にユーザーが増加
  • スケールアウト／アップが効かない

性能を意識したアーキテクチャ例

  • Read Replicaによるオフロード
  • キャッシュによる高速化
  • シャーディング
  • スケールアウト

方針

発生する問題

  • リージョン障害でアクセス不能
  • Read Replica⇒更新の反映遅延
  • Cache⇒データ不正語
  • Stanby⇒切り替え時間
  • シャーディング⇒区分の変更が大変
  • APサーバ増えた分のコネクション数増加

⇒リソースを使えない問題と使い切る問題

問題の分類

  • 性能
    • 更新の性能限界
    • リソースを使い切る
    • リソースを使えない
    • 区分変更
  • 可用性
    • 長い切り替え時間
    • データ不整合
    • 更新の反映遅延
    • ダメなコネクションを取得

リソースが使えないとは？

リソースが足りてないケース

  • スレッドプールの枯渇
  • オブジェクトプールの枯渇
  • コネクションプールの枯渇

一人しか処理できないケース

  • オブジェクトロック
  • 行ロック

更新の性能限界に繋がる

テストケースA

  • APサーバーは徐々に増
  • DBのCPUが頭打ち

テストケースB

  • ほとんどCPU使えていない

何を気にしないといけないのか？

  • 負荷×インフラ×アプリ

負荷で気にすること

  • 負荷全体に言えること
    • 今の負荷は将来の負荷ではない
  • システム全体の負荷
    • 実際に起こり得る混合の負荷
  • 特別な状況での負荷
    • キャンペーン時に単一商品への大量アクセス

インフラで気にすること

性能

  • スケールアウト／イン
    • 増やすだけでなく減らすのも難しい
  • スケールアップ／ダウン
    • アウト／インかアップ／ダウンか運用設計して考える
  • スレッド、コネクション
    • スケールアウトは注意
    • クラウドだと気軽にスケールアウトできるけど1,2台ぐらいしか事前に試さないことも

可用性

  • データストアの可用性
  • 障害時の復旧時間
    • 絶対落ちる前提で普段から確認
    • 障害が起きた時しかわからない

インフラの性能で気にすること

スケールとリソース

  • スケールアップしてリソースを増やす
    • リソース数を増やすのは限界があるので注意（CPU数やメモリ）
  • スケールアウトしてリソースを増やす
    • 他のインスタンスのリソースを使い切ってしまう可能性があるので注意（コネクションなど）

インフラの可用性で気にすること

  • アプリにインフラを極力意識させない
    • インフラの構成とアプリの設計を分離（疎結合）
    • アプリの問題なのかインフラの問題なのかの切り分け
  • 全てのそうでSPOFを取り除く
    • 全ての役割のインスタンスを複数用意
    • リージョンをまたいだ環境の構築
  • 高可用性構成の切り替え時間を短くする
    • 自動で検知
    • 自動で切り替え
    • 切り替えが短時間で完了

アプリケーションで気にすること

性能

  • ロック
    • オブジェクトロック
    • 行ロック・表ロック
  • スケールアウト
    • DataStoreがスケールアウトした際にアプリが持つ接続が再分散する

可用性

  • スケールイン
    • 落ちた時に影響がないように

ロック時間が長い

  • 処理を減らす
  • CPUを早くする
  • 無駄な時間を極力短くする

スケールでは対応できないので注意

アプリケーションの可用性で気にすること

スケールイン

ロックについて

  • ロックしないとどうなるか？
    • 在庫数よりも多くのものが売れてしまう
    • ホテルで部屋数以上の予約が入る
  • ロック開放待ち中のスレッドは何も処理しない
  • DataStoreが低レイテンシーなら性能が上がる

Cache

Cacheを使えばできるんじゃない？

テストケースA

  • APサーバーがCPU使えるようになった
  • CacheのCPU⇒DBのときと同じようにはCPU頭打ち
  • スループット7.8倍

テストケースB

  • Cache⇒CPUを使えていない
  • DBとあまり変わっていない

結果

  • Cacheは条件が揃わないとあまり早くならない
  • ロック期間は変わっていない
  • テストケースAは早くなる
  • ECサイトなら参照系だけなら早くなる

In-place処理

テストケースBを早くするにはどうしたら良いのか

  • データを取るのが遅い
  • データのある場所で処理しよう

これまでの処理とIn-place処理

  • APサーバで処理⇒データがある場所で処理する
  • 5往復が2往復で済む⇒通信が早くなる

Entry-Processorを使うと通信をまたがない

インフラはどうしよう？

  • 高速
  • リソースをきちんと使い切る
  • スケールアウトできる
  • SPOFがなく自律的
  • データストア内で整合性
  • リージョンレベルで冗長化
  • アプリは上記を意識死にで良い

インフラとして望む要件

  • ロック期間が短くて済む
  • 足した分だけスループットが増える（スケールアウト）
  • ブロック処理がない（リソースを使い切る）
  • ノードが落ちても気にしないで勝手に復旧（SPOF）
  • データストア間での整合性を担保
  • リージョンレベルで冗長化
  • アプリはインターフェースを実装するだけで良い

こんなアーキテクチャが欲しい

  • とにかく速い
  • 拡張できる
  • 障害に強い

  • 実装が簡単

  • APサーバ…アプリの実装が楽

  • Cache…ブロック数が少ない
  • DataStore…永続化と整合
  • リージョン…別リージョンで冗長化

In-Memory Data Grid

Cohorence

  • 標準に準拠
    • JCache
    • Lambda式
    • 他言語にも対応
  • 処理が速い
    • In-Place処理
    • CacheStore
    • 分散
  • 高可用性
    • 冗長化
    • Eviction…アクセス頻度が高いものだけキャッシュ
    • Federation
    • Persistence

テスト

まとめ

テストケースA

  • データストアは常にCPUを使えていたが処理効率の違いからスループットに違いがある
  • APサーバはレイテンシが短いとたくさん処理できてCPUをたくさん使う

テストケースB

  • ロック時間が影響
  • In-place版はロック時間に通信を含まないのでCPU時間だけのロックで済む

まとめ

  • In-place処理で低レイテンシが実現
  • In-Memory Data Gridは性能・可用性でメリットがいっぱいある
    • 高可用性（ゾーンレベル、リージョンレベル）
    • 必要なCPU数削減

もしもみなみんがアプリケーション開発者だったら

みなみん さん

システムによくある問題

  • インフラを使い切れないアプリ
  • 性能限界

  • 可用性の問題

  • 運用が大変で開発に注力できない

  • 問題を分析・改善できない

性能を意識したよくあるアーキテクチャ例

  • Read Replicaによるオフロード
  • キャッシュによる高速化
  • シャーディング スケールアウト

可用性を意識したよくあるアーキテクチャ例

性能と可用性を意識したアーキテクチャの具体例

  • Read Replicaを並べる
  • シャーディングも可能
  • Stanbyでデータ同期

よくある問題の例

  • 書き込みと参照を分ける⇒書き込みが遅い
  • Read Replicaを増やしても参照が遅い
  • APサーバからの制御が難しい
  • Stanbyの仕組みを作るのが大変

こんなアーキテクチャ

  • Read Replicaのチューニング案を提示
  • スケールアウトが簡単
  • Stanbyの構築も簡単
  • 接続先を意識させない

何を気にしないといけないのか？

  • 性能と可用性

インフラの性能で気にすること⇒スケールとリソース

  • スケールアップでリソースを増やす
  • リソース数を増やすのは限界がある
  • スケールアウトしてリソースを増やす
  • 他のリソースを使い切ってしまう可能性

可用性で気にすること

  • アプリにインフラを極力意識させない
  • 高可用性構成の切り替え時間を短くする
  • オペレーションミスのリカバリ

アプリケーションで気にすること

  • パラレル処理
    • 他の処理に影響を及ぼさない適切な並列度
    • データ配置や処理性を意識した分散
  • スケールアウト

オペレーションミス

よくある解決方法

  • DataStoreを停止してバックアップからリカバリ
  • スタンバイへ切り替え

実際には

  • バックアップから戻すには時間がかかる
  • バックアップが使えない
  • スタンバイが使えない
  • バックアップやスタンバイが元々無い

理想的な解決方法

  • ミスごとの適切なリカバリ方法
  • 簡単に取得できてきちんと戻せる
  • 簡単に構築できて切り替え後にきちんと使えるスタンバイ

更新系の性能

よくある解決方法

  • Read Replica⇒参照処理をオフロード
  • シャーディング
  • インスタンスサイズのスケールアップ

スケールアウト

  • スケールアウトしたノードに処理が分散しない
  • 特定のノードに偏る
  • コネクションが残る
  • キャッシュしない

理想的な解決方法

性能問題

  • コストがかかる
  • 単純なHW増強では解決しない
  • チューニングを試せない、環境がない

ベターな解決策

  • 自動的に分析に必要な情報収集
  • 問題の特定
  • 改善案の決定／適用
  • 自動性能テストの実施

ベストな解決策

  • システムが改善案を提示
  • 本番データを使って自動テスト

⇒簡単、高効率、高性能なシステム

オペレーションミス対策

  • Flashback tecnologies
    • 特定時点に戻すことができる
    • DB全体のリストアが不要
    • 過去データを参照可能
  • Recovery Manager
    • バックアップを利用した復旧
    • オンラインでブロック単位でのリストア
  • Data Guard
    • リアルタイム・データベース複製
    • 自動検知・自動切り替え機能

更新系

  • Real Application Clusters
    • サーバ数を増やしてスケールアウト
  • Sharding
    • 複数のデータベースに分散配置
  • Active Data Gurard
  • GoldenGate

スケールアウト

  • Active GridLink for RAC
    • RAC側から状態を通知
  • ランタイム接続・ロード・バランシング
    • RACの負荷状況判断
      • WebSessyon ・アフィニティ
  • Single Client Access Name
    • 接続リクエストのリダイレクト
  • データベース・サービス
  • Automatic Storage Management
    • ストレージの分散配置・再配置の自動化

可用性

  • Active GridLink for RAC
    • RAC側からの通知・連携
  • Fast Connection Failover
    • コネクションプールとの連携
  • Application Continuity
    • フェイルオーバーを透過的に実行

性能問題

  • Compression
    • データ圧縮でI/O量削減
  • Partitioning
  • Parallel Query
    • パラレル化で複数CPUコアを利用
  • Database In-Memory
    • インメモリ化
    • 列指向で演算処理を高速化

情報の取得・分析

  • Diagnostics Pack
  • Tuning Pack
    • パフォーマンス管理
  • Real Application Testing
    • 性能問題を未然防止
  • Enterprise Manager
    • GUIで管理・運用ツール

ここまで色々あげてきたものを使うのを考えるの大変

全部自動化できたらうれしい

自律型データベース

  • Self-Drivision
  • Self-Securing
  • Self-Repairing

Autonomous Data Warehouse Cloud

リンク・転載は法令・公序良俗に反しない範囲で自由です／著作権は全て著作者に帰属します