mono(0w0)ログ

読んで、体験して、自分でやってみた記録

Tech Deep Dive #2 in Osaka に参加して

前提となる知識にビビりながら参加してきました。 ちょうど今回のテーマである性能について考えることが多くなっていたので良かったです。

前提知識について

全体的に理解しやすかったですし、思っていたほど難しくはなかったです。

ただ、アプリやシステムのコーディングだけ経験しましたという人は辛いかも。設計してコード書いて、動かして、性能でないことにハマって、どうやったらいいか悩んで、みたいなところを一度は経験している方が納得しやすいと思います。

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

知らなかったこと、新鮮だったこと

業務ではオンプレの開発にしか携わったことがないので、クラウドを前提とした時に問題となりやすいことについては新鮮でした。

  • クラウドではアプリ性能がコストに直結する
  • スモールスタートでも早期にスケーリングを考慮する
  • スケールアップ・スケールアウトしやすい環境だからこそ安易な実施は状況を悪化させる

再確認できたこと

  • 気にすべきは「負荷×インフラ×アプリ」
    • どこか1つではなくシステム全体を見る
  • 負荷
    • 全体と特殊な条件
    • 今の負荷と将来の負荷は違う
  • インフラ
    • スケールアップには限界がある
    • スケールアウトは他のリソースを枯渇させるかもしれない
  • アプリ
    • ロック時間を小さくする
      • 秒間の最大処理件数=1秒/ロック時間
    • 非同期はビジネス要件のバランスで要否決定

インメモリデータグリッド

Oracle Coherenceを利用した場合の性能改善には素直にスゲーと思いました。

ですが、それを導入するには、ビジネス要件とかコストメリットとか諸々のバランスを考慮しないといけないわけで。 このミドルウェアがマッチするシステムとはどのようなものか? その辺りの判断ができるようになるために、技術や製品について理解を深めないといけないなぁと考えてます。

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

よくある問題とその解決方法について、製品機能とともに説明されていました。

  • オペレーションミス
    • ミスの影響範囲を小さくする
    • 復旧できてこそのバックアップ
    • 簡単に切り替えられるスタンバイ
  • 更新系
    • Read Replicaによる参照オフロード
    • シャーディング
    • DataStoreのスケールアップ
  • スケールアウト
  • 性能
    • 情報の自動収集
    • 問題の特定と改善案の決定・適用
      • 時間↓ = 処理量↓ / (速度 * 並列度)↑
    • 自動テスト
    • 上3つを自律的に行うシステムがベスト

各改善方法に対してOracle Databaseの機能で実現できるよという紹介があり、今後のビジョンとして自律型データベースを示されてクローズされました。

各機能は知っているものもありましたが、そうでない方が多く色々と参考になりました。今のプロジェクトで利用している機能についてインフラの人に聞いてみたいなーと思っています。

自律型データベースについては、「でもお高いんでしょう?」という声の通り、それすらも機能の一部でありビジネス要件の解決に導入するか否かの判断が大切だと思います。 あったら嬉しいとは思いますが、アプリ側とインフラ側をそこまで疎にしていいんかなーという漠然とした不安感があります。言語化難しい(´-`)

最後に

総合的な視点でのお話でとても良かったです。 ミドルウェアやインフラについてはもっと知識を深めていきたいので、また開催されるのであれば、是非参加したいです。