2017年3月11日(土)に開催されたJAWS DAYS 2017。
今年も当日は参加できなかったのですが、前年同様公式サイトの運営（保守）や広報オーガナイザー的な感じで携わりました。
あまりにも昨年同様の記事になりそうなので、今年はちょっと違うことを書いておこうと思います。
コミュニティベースのイベントサイト運営での参考になれば幸いです。
目次
Webサイトの設定などの話
WordPressの設定やGitとの連携は JAWS DAYS 2017 用のGitHubリポジトリのWiki に掲載してますので、そちらをご参照ください。
イベント終了後に静的HTMLへの書き出しや書き出したファイルを AWS S3 にあげてWebサイトホスティングにするところまで記載してます。
- AWSでなくてもGitが使えるWebサーバーを準備できる
- WordPressのインストールと運用を問題なくできる
- Gitの運用ができる
- WP-CLI 使える
これらの条件を満たしていれば Wiki を読めばイベントサイトの立ち上げはできるでしょ、という不親切（ぇ）説明です。
質問などは該当リポジトリの Issues までどうぞ。
WordPressで工夫した話
誰でも入力しやすくするという前提で管理画面側は作り込んでます。
今年は去年の反省点を踏まえ、登壇者ベースだった部分をセッションベースに変更しています。
ACF使いまくりに見えますが、入力欄はACFでも中身はカスタムタクソノミーになってる項目があります。（カテゴリー、会場、難易度）
これは表側（管理画面側）でカスタムタクソノミーで絞り込んだりする都合です。表側ではセションアーカイブではカテゴリーによるグルーピング（かつその中で順序）で表示し、管理画面側のセッション一覧では50件近くのセッション情報を探しやすくするようタクソノミーで絞り込む機能を追加してます。
このように WordPress の場合、絞り込みなど投稿に紐づく情報でクエリ操作する場合はカスタムフィールドよりもカスタムタクソノミーのほうが向いている場合が多いです。
カスタムタクソノミーの作り方も工夫していて「投稿編集画面に出さない」「アーカイブを作らない」などは全て register_taxonomy() で設定できるのでドキュメント読むのをおすすめします。
https://codex.wordpress.org/Function_Reference/register_taxonomy
他に実装したちょっと便利なコードは Qiita に書いてますんでそちらもどうぞ。
インフラの話
永代供養（＝静的HTMLに変換してS3でホスティング）まではEC2 t2.micro インスタンス＋網元AMI（WordPress powered by AMIMOTO (HVM)）で運用してます。
一番アクセスなどの多かったイベント前後の3日間（3/10〜3/12）の、Googleアナリティクスの時間別ページビュー、CloudWatchのNetworkInとCPU使用率のグラフがこれです。
土曜9:00台（開場〜セッション開始前）の時間帯が一番アクセスが多かったです。
（なお、管理画面側とWordPressログイン時は計測してないです）
NetworkIn（青／右側）とCPU使用率（オレンジ／左側）を見ると、直前ニュースを更新などした前日のほうがCPU使用率が高く（それでも10%超えないですが）、更新がない当日はNetworkInが多い＝アクセスが多かった点が見受けられます。アクセスが多くてもNginxのキャッシュを返してるのでCPUはさほど上がってないです（5%超えない）。
公式サイト立ち上げから通してみても、1月末のWordPress 4.7.1 及び 4.7.2 のアップデート適用時にCPUが80%を超えましたが、それ以外の運用では10%も超えませんでした。
単純に見て10倍程度のアクセスがあっても t2.micro で十分耐えられると思います。
なお、インスタンス起動時期が微妙だったのでPHP7にはしてないです。執筆時には網元AMIもPHP7がデフォルトになってますので、CPU使用率の観点からすればもっと余裕が生まれていると思います。
という去年今年2年連続でWebマスター的なことなどを 2017.3.28(火) に行われる「[仙台] JAWS DAYS 2017 Recap!」でお話しますのでよろしければそちらもご参加ください。
（なお、各地のJAWS-UGで JAWS DAYS の報告会が開催されますが、公式サイトのお話をするのは仙台だけです）