こんにちわ。Openlogi Advent Calendar 18日目です。

前回、前々回と、GraphQLの実装について書きました。引き続きGraphQLについてです。

GraphQL で一番語られがちなのは、REST APIではできない柔軟なクエリについてですが、実際にアプリケーションで利用するにはいくつか超えなければならないハードルがあります。

個人的に上げるとするならば、認証、認可、パフォーマンスといったところでしょうか。本記事ではこのうちパフォーマンス周りのアプローチについて紹介していこうと思います。

さて、RESTの場合、特定のエンドポイントについて、取得するデータ量や、どの程度の時間がかかるかを想定するのは特に困難ではありません。しかし、GraphQLではクライアントサイドで取得すべきデータを定義するため、非常に高負荷なクエリが実行される可能性があります。

例えば、前回の記事では以下のようなスキーマを例に挙げました。
ここでは、ユーザーと、そのユーザーの閲覧できるフィードが存在することを表しています。

type Query {
  viewer: User
}
type User {
  id: String
  name: String
  feeds: [Feed]
}
type Feed {
  id: String
  title: String
  body: String
  author: User
}

こんなクエリを書いて、トップページのタイムラインを表示することを想定してます。

query {
  viewer {
    id
    name
    feeds {
      title
      body
      author {
        id
        name
      }
    }
  }
}

しかし、一方このスキーマに対しては、このようなクエリを書くことも可能です。（他人のフィードの一覧が見れるべきかというのはここでは気にしないことにします。）

query {
  viewer {
    id
    name
    feeds {
      title
      body
      author {
        id
        name
        feeds {
          title
          body
          author {
            id
            name
            feeds {
              // 以下無限ループ
            }
          }
        }
      }
    }
  }
}

このように、GraphQLでは数千・数万のデータベースアクセスが簡単に発生させることができる危険をはらんでいます。ということで、GraphQLのパフォーマンスについてのアプローチをいくつか紹介します。

クエリにバリデーションをかける

リクエストサイズのバリデーション

まず低レイヤのアプローチとしては、リクエストに送られてくるクエリのサイズで制限をかける方法があります。単純にクエリのサイズで制御をかけましょう。

クエリの構造に対するバリデーション

もう少し複雑に行うのであれば、クエリのネストの階層を見る方法もあります。GraphQLのクエリはASTに変換して表現できるため、一定以上の深さは許可しないという制御をかけることも有用ですし、特定の構造のクエリを許可しないようにしても良いかもしれません。

タイムアウトを行う

各Resolverの処理で、タイムアウトをかけることも有用です。GraphQL query timeout and complexity management にあるので詳細はこちらを。一定時間を超えた場合に処理を止め、以降のResolverが発火しないようにするアプローチです。

永続化クエリ

問題なのは、想定していないクエリが送られてくる可能性があるということです。なので、あらかじめ決められたクエリのみを許可しましょうというアプローチです。
これは、persistgraphqlのようなライブラリを使うことで実現できますが、雑にまとめると、

クライアントサイドでビルド時に利用するクエリの一覧を取得する。
それぞれのクエリをハッシュ化し、実際のクエリとハッシュ値とのマッピングを作成する
クライアントサイドからはハッシュ値を送り、サーバーサイドでクエリを解決して実行する

といった事を行います。

ネットワークパフォーマンス

GraphQLでは取得するデータの構造をクライアント側からリクストに含めるため、クエリのリクエストサイズが膨大になるいう問題が発生しがちです。これは上述の永続化クエリでハッシュ値を利用することでも対策できますが、後述のApollo Engineのauto-persisted-queryというものもあります。
これは、上述の永続化クエリとは異なり、リクエストサイズの削減のみを目的としています。初回実行時にサーバーサイドでクエリとハッシュ値をキャッシュしておくことで、2回目以降はクライアントからハッシュ値のみを送ることでクエリの実行を行うことを可能にします。

n + 1 問題

少し毛色の違う内容ですが、GraphQLでは基本的にEager loadingのような仕組みを利用することができないため、単純に実装すれば必ず n + 1 問題が発生します。Facebookの dataloader はこの問題をシンプルに解決してくれます。js以外でも同じようなライブラリがあるため探してみてください。

計測について

いずれのアプローチをとるにしろ、パフォーマンス改善には計測が必要です。
GraphQLの計測は、Apollo Engineというサービスを利用して非常に簡単に行うことができるのでこれを紹介します。

何ができるか

Apollo Engineでは、以下のような情報を見ることができます。

クエリの実行日時、処理時間の情報

各クエリの処理時間とその件数の統計

各ノードに関する処理時間の統計

特定のリクエストについて、各ノードの処理時間

そのほか、エラーの発生率などの情報なども確認することができます。ちなみに1M Request/Monthまでが無料となっています。開発環境だけでも、問題のあるクエリが簡単に発見できるので入れておいて損はないです。

nodejsであれば、こんな感じで埋め込むことができます。


var { Engine } = require('apollo-engine');

const engine = new Engine({
  engineConfig: {
    apiKey: process.env.APOLLO_ENGINE_API_KEY,
    logging: {
      level: 'DEBUG'
    }
  },
  graphqlPort: PORT,
  endpoint: '/graphql',
  dumpTraffic: true
});
engine.start()

app.use(engine.koaMiddleware());

最後に

AWSのApp SyncでもApolloを利用した、オフライン対応やリアルタイムアップデートの機能が発表されました。これを機にGraphQLのエコシステムがさらに成長してくれるといいですね。

GraphQL でのパフォーマンス関連の問題について色々紹介する