すのふら

すのふら

日々の備忘録

物語を俯瞰する人間を見る / 『劇場版SHIROBAKO』を見た

アニメ映画を見に劇場へよく足を運ぶんだけど、感想は大体ツイッターに書いて終わらせてしまうことが多い。

そもそも感想を書くのがそんなに得意ではないし、監督がどうとか演出がどうとかの知識もなく的を射ていない可能性も高い、というのが理由だ。

ただSHIROBAKOについては、今まで関連記事も書いてきたということもあったし、見たときに俺の中で整理できていないところもあって整理のためにも感想を書く。

snofra.hatenablog.com

snofra.hatenablog.com


全力でネタバレをするので、気になる人は見ないほうが良いです。


















劇場版『SHIROBAKO』のあらすじ

テレビ版の後数本アニメ作品を制作した後、制作していたアニメが制作中止になった。理由は契約上の問題になる。

丸川社長が制作中止を話したときには、かなり余裕をもって進行しており、制作陣は寝耳に水だった。
それぞれこの中止を重く引きずりながら武蔵野アニメーションに留まるもの、去っていくものがいた。

武蔵野アニメーション自体も倒産までにはならなかったが、テレビ版のような明るい感じは姿を消し、斜陽のアニメーション制作会社に戻っていた。

そんな中、『空中強襲揚陸艦SIVA』という劇場向けアニメが、制作会社側の怠慢によって頓挫の危機にあった。
その制作をタイトル以外はまるまる白紙の状態の作品を武蔵野アニメーションは引き受けることにした。

制作期間がかなり短いので、作品を制作するためにかつてのメンバーを招集、アニメを制作していく。

作品が完成に近づいていくときに、『空中強襲揚陸艦SIVA』を頓挫させたアニメ制作会社から権利についてのいちゃもんがあった。
このタイトルを勝手に使うとはなにごとか、アニメを制作しないとは言っていないというものだ。

ただ頓挫させたアニメ会社はその権利を主張するための義務を果たしていなかった。権利問題をなんとか回避してかつてのアニメ制作中止を阻止することができた。

アニメが完成(完パケ)したが監督があまり腹落ちしていなかった。
スタッフ全員で話し合った結果、ぎりぎりまで粘ってアニメをよりいいものへブラッシュアップすることにし、封切当日を向けた。

次回のアニメ制作は第三飛行少女隊の続編というホワイトボードで物語は終わる。


アニメを作る人たちの話ではなく、アニメを作る話であった

俺の中であれ?ってまず思ったのは、この物語が「アニメの作る人たち」の話ではなく、「アニメを作る話」であったなっていうこと。

テレビ版の『SHIROBAKO』も確かにアニメを作る話ではあったんだが、物語の中心はあくまで作っている人であったのかなと思う。

それはたどり着きたい場所について考える姿だったり、
f:id:snofra:20200310170754j:plain
©「SHIROBAKO」製作委員会

喧嘩するシーンだったり
f:id:snofra:20181215000823j:plain
©「SHIROBAKO」製作委員会

キャラクターの成長だったりする。
f:id:snofra:20200310171101j:plain
©「SHIROBAKO」製作委員会

ただ、劇場版はそうではなかった。


劇場版はあらすじにも書いた通り、劇場版を短期間でどう作り切るのかという話だ。

テレビ版の感覚なら、原画を撒くことができないなど制作という仕事の問題や、制作中に発生するメンバー内の軋轢や成長を描くものである。

だが、それを描くシーンがかなり少なかった。
どちらかというと外から俯瞰しているシーンがかなり多かったと思う。


劇場版を見終わったときに、何というか俺はこれを見たかったのか?
見たかったのはもっと作業者たちの泥臭さとかそういうことなんじゃないのか?
とそんな気持ちになった。

なぜこういうことになってしまったんだろうと思ったときに、宮森あおいが偉くなりすぎた問題があるのでは?と思った


宮森あおいはもうひとつの作品に深く肩入れできない

宮森あおいは劇場版ではプロデューサーだ。
プロデューサーはテレビアニメ版では、渡辺隼のポジションになる。


アニメ版の渡辺隼が映っていたシーンは、

アニメの放送ができないという状況で、武蔵野アニメーションのパワーでは制作できない、ないてくれという序盤最大の山場の重要な局面のシーンや、
f:id:snofra:20200310171852j:plain
©「SHIROBAKO」製作委員会

アフレコのシーン
f:id:snofra:20200310172008j:plain
©「SHIROBAKO」製作委員会

次の作品を持ってくるための接待、もしくは打ち合わせとして麻雀をやっているシーン
f:id:snofra:20200310172117j:plain
©「SHIROBAKO」製作委員会

このあたりかなと思う。

彼は基本的に今、そして次のアニメ制作自体を決める権限、アニメ業界の政治の世界の中にいると言える。

仕事をもってこればいいという話が、アニメ版で新川奈緒の台詞としてあるが、ここからも彼はアニメの制作自体に肩入れせず、重要な局面のみ登場し決定を行う人間として描かれる。

現実のプロデューサー職がこれと同じなのかは俺には判断できないが、少なからず決定をしなければならいというロールであることは間違いないだろう。


劇場版は、宮森あおいはそのロールにいる。
ということはかつて第三飛行少女隊制作の際、彼女がそうだったデスクのポジションがいたはずだ。
おそらくその人から話を聞いているのだろう。

終盤、宮森あおいがやらなきゃいけないことについて、ミムジーとロロと話をする。
いくつかやらなきゃいけないもののの中で、最後にロロは「アニメを完成させる」という台詞を言う。

これは宮森あおいの今のロールでジャッジする権限を持っており、ジャッジしなければいけない人間であることを表しているのだと思う。


だから彼女は判断する。
アニメを(自分たちの最高だと言える形で)完成させるという判断をするのだ。


高いロールが主人公のつまらなさ

上でいった通り、この物語の主人公は宮森あおいであり、宮森あおいはアニメ制作という場においてかなり上の立場にいる。

この高いロールであることの問題は、話が政治になりがちであることだと思う。
今回も最終的に権利の話になる。

劇場版ではこの権利の話を第三飛行少女隊政策の際と同様にある程度デフォルメして描いている。
f:id:snofra:20200310172554j:plain
©「SHIROBAKO」製作委員会

何故ここまでデフォルメするのかというのはやっぱり正面切ってやる話としてはどうしても面白くないのではと推測する。

でもアニメ版の『SHIROBAKO』で俺が政治戦について何も感想を抱かなかったのは、テレビアニメ版は敵(トラブルメーカー)が社内と社外にいたからだ。

ただ今回描かれる敵(トラブルメーカー)は社外のみになる。
そして社外はアニメ制作自体には関与してこない。

この状況で揉めなければならないという状況は、権利にならざるを得ない。

ただ権利の話は、高い役職の人たちの中で完結されてしまう。
丸川社長時代に制作中止の話をされたときに、スタッフは寝耳に水で質問をしたが、相談ではなく決定を伝えたシーンとなっている。


宮森あおいがもし『空中強襲揚陸艦SIVA』を制作中止にしなければならないという判断を下すにあたって、自分の立場上「上山高校アニメーション同好会」のメンバーに相談することはできない。

権利の話をひっくり返す情報を持っている人間がいないからだ。
(そもそもみんな武蔵野アニメーション所属ではないというのも理由になるとは思うが)

この物語が俯瞰する物語だなと思ったのは、彼女がそういうロールなので、こういう感じの映画になってしまうのは当然だと思う。


渡辺隼との話が足りなかったと思う

そのうえでこの物語は渡辺隼というキャラクターが正しく扱えなかったのかなと思う。
何というか、この物語において渡辺隼は何も言わないのだ。

作品を俯瞰する宮森あおいを俯瞰する立場にいるように見えた。
(もしかして、彼が会社の社長というロールが原因なのかもしれない)

終盤のシーンでアニメを(自分たちの最高だと言える形で)完成させるという判断をするが、彼はおそらくそういう判断をしないはずだ。
納品3週間前でどのくらいのリテイクになるのかもわからないという状況は「完成できないかもしれない」リスクがある。

えくそだすっ!』での武蔵野アニメーションでは難しいという判断は絵コンテを読んでの判断だった。

今回は、それよりももっと分が悪い状況になる。
監督が修正するリードタイムがどの程度なのかもわからない。これが3週間かかるとアニメを完成することができない。

劇中この判断に何も言わなかったのは、きっと何かこれについて何か話があったのだろうと思う。
おそらく上である程度話してリスクヘッジしたうえで、最終的にスタッフに相談するという判断に至ったのだと推測するが、この物語で描くべきはここのシーンだったのではないか?と俺は思う。

何かを決定することの少なさを俺は感じた。

上層部で決定する話があまりないので、新規キャラクターだったウエスタンエンタテイメント側のアシスタントプロデューサーである宮井楓がいまいちパッとしなくなったのではないかと思う。


藤堂美沙の物語でもよかったのではないか

もうひとつ見ていて気になったのは、藤堂美沙の扱いだ。

彼女は会社でCG班のリーダーだったが、メンバーは向上心の薄いキャラクターや、なかなか進捗をあげられないキャラクターの面倒を見ていた。

そして中盤、進捗を挙げられなかったキャラクターが得意分野で才能が開花されて焦る、タスクを抱え込みすぎてしまうという状況に陥る。

この状況の最終的な解決が、いい感じに役割分担をしたらいいよねというものだった。

そういうものなのか?ワンエピソードであっさり腹落ちできるものなのか?

彼女の中での焦りや悩みによって自身が、ボトルネックになってしまうという状況は、『SHIROBAKO』くささとして映画でもっと深掘りしていったほうが良かったのではないか?と俺はそう思った。


序盤かなり辛かった

ここからは俺のさらに純粋な感想になる。

序盤武蔵野アニメーションが斜陽であることを表すために、第一話と対比していた。
ラジオのアニメ番組はアニメが減っているや予算がないと言い、武蔵野アニメーションの建物や社用車は老朽化している。

えくそだすっ!』第一話の放映シーンではたくさんいたスタッフが全くいない。
なんというか、この序盤だけで悲しくなって心が辛かった。
だって、俺はあの時のアニメ版が終わった状態の延長として見に来ているんだから。

だからこの作品はダメっていうわけではなくて、出ていくという判断を冷静にされているという状況という妙なリアルさがあるなーっていう感じだった。


遠藤さんよかった

制作中止で心が折れてしまった遠藤をみんなで救い上げるシーンは『SHIROBAKO』っぽさがあってよかった。

瀬川さんと結構深く付き合いあったんだなーというところや、下柳さんとすごく仲良くなっていて、苗字呼び捨てだったりこれはお前にしかできないと設定資料渡したりといいシーンだなーっていう感じだった。

遠藤さんの奥さんとのシーンは、妻帯者としてはファンタジー度合いがとんでもなく高いなwと思いつつも、こういう最後の背中を押すのは、やっぱり家族なんだよなーって思った。


その他思ったこと

山田さんはなぜあんな変なポジションだったんだ?

杉江さんのヒゲは俺はちょっとなと思ったのと、ワイフって言っていて「え、ワイフ?」って4年間でちょっとどうしたっていう気持ちになった。


最後に

俺のこの感想も本質を得ていない感想の可能性が非常に高いので、上映しているうちにもう一回見ておきたい。

新アニメ『アイカツオンパレード!ドリームストーリー』や新プロジェクト始動!など盛りだくさん! 「アイカツ!」シリーズについて発表されたこと

今後の「アイカツ!」シリーズについて発表が2020年3月8日の19時に発表されました!*1
本来はライブ最終日に公開される内容だったかと思うので、コロナウイルスでの中止が残念な限りですね。

重大発表と銘打たれた内容は以下の3つとなります。

重大発表①:
公式YouTube「アイチューブ」にて『アイカツオンパレード!ドリームストーリー』が配信スタート!

重大発表②:
アイカツ!シリーズ 新プロジェクト始動!

重大発表③:
重大発表①に伴って、DCDも『アイカツオンパレード!ドリームストーリー 第1弾』が稼働!


それぞれの発表について思うことを書いてみます。


アイカツオンパレード!ドリームストーリー』


WEBアニメ「アイカツオンパレード!」プロモーションビデオ

初回の配信は、2020年3月8日土曜日午前11時からです。

舞台がドリームアカデミーになり、主人公が姫石らきから音城ノエルに変更になった形になります。(ダブル主人公?)

音城ノエルについては、初代『アイカツ!』に登場していたキャラクターで、終盤にドリームアカデミーのアイドルとなったため、彼女の活躍を見たいという人も多かったと思います。

劇場版『アイカツ! 〜ねらわれた魔法のアイカツ!カード〜』でも登場しているというところからも、人気キャラクターのひとりだと思います。


約7年6ヶ月続いていたテレビ放送が終了

番組の放送自体がテレビ放送からYouTubeに変更される形となりました。

これで『アイカツ!』の第1話(2012年10月8日)から約7年6ヶ月続いていたテレビ放送から一旦撤退となります。

これについてコンテンツ自体の売上が低迷しているので撤退するという見方もできるかもしれません。
ただ、俺はそうは見ていなくて、バンダイナムコが最近試しているYouTubeでアニメを配信することで子供に目に触れる機会を増やそうとしているのかなと思っています。

YouTubeで放送していたバンダイナムコ作品としては、『ガンダムビルドダイバーズRe:RISE』があったけど、これもガンプラを子供たちにどう売り込んでいくかという施策のひとつとして実施されたのかなと思います*2

ここから見てもバンダイナムコ側が、アイカツ!」シリーズを今後コンテンツの種まき時期であると判断したのかなと(勝手に)思っています。

とりあえずは『アイカツオンパレード!』時期に抱いていた「コンテンツが終わるのでは?」からは脱したのかなと。


初回は最終回も含め1時間スペシャル扱いか

初回は2020年3月8日土曜日午前11時からとあるので、おそらく初回はアイカツオンパレード!』最終回から『アイカツオンパレード!ドリームストーリー』第1話までの1時間スペシャル扱いになるのではと思っています。

「初回は」という文言から、2回目以降は土曜日ではない可能性もあるのかなと思います。

放送話数も1クール(12~3話)なのか、それとも2クールなのか、特別編なのでそもそも毎週という扱いではないのか。

情報として分からないところも多いので、それは初回放送後に分かることかなと。


アイカツ!シリーズ 新プロジェクト


アイカツ!シリーズ 新プロジェクト始動!

短い情報で分かったこととしては

  • 今秋からテレビ東京系で新シリーズのアニメ放送が決定
  • 新シリーズからのDCDは新筐体で稼働
  • 詳細については6月に公開

正直、新筐体で稼働するとは思わなかったというのが正直なところです。

2016年5月から現在の筐体でスタートし、今年で4年目ということもあっての変更だと思われるが、現在の「アイカツ!」シリーズの売上的に新筐体に投資する可能性は低いのかなと思っていたのでかなり驚きました。

snofra.hatenablog.com


新筐体からわかること

新筐体は当然まだイメージでしかないが、現在の筐体と比較して分かることもいくつかあるように思えます。

現在の筐体がこれです。

f:id:snofra:20200309150504j:plain

次の筐体サンプル画像はこれです。

f:id:snofra:20200309150618p:plain


新旧の筐体を比較して、ぱっと見見えるのは画面が2分割されているデュアルディスプレイのかなーと見えますね。
(演出の都合で画面がふたつになっているように見えているだけ可能性もあるけど)

おそらく下の画面は傾斜して、上の画面は垂直に立つのかなーと予想しています。

旧筐体ではタッチパネル部は傾斜していたけど、新筐体では傾斜していないように見えますね。

カード2次元バーコードの読み込み部がないので、おそらくプリチャンのような筐体にカードを入れて読み込ませる仕組みになるのでは?と妄想してます。


DCD『アイカツオンパレード!ドリームストーリー 第1弾』


データカードダス アイカツオンパレード!ドリームストーリー プロモーションビデオ

テレビアニメと連動した形ですね。

とはいえ、DCD『アイカツオンパレード! 第3弾』は2020年1月30日稼働で2020年3月25日までの稼働で56日間稼働していることになるので、特別少ないわけではないです。*3

プロモーションビデオで、新曲の「トワイライトエトランゼ」も流れました。


ドリームスクールグランプリ出場学園プロモーションビデオ

ここの注目は歌唱担当の「あやね」というところだと思います。

音城ノエルを担当している声優さんは加隈亜衣さんなので、アイカツフレンズ!』から続いていた歌唱担当=声優のシステムは撤廃されたということになるのかな思います。

じゃあ歌唱担当の「あやね」って誰なんだというところではありますが、正式発表されているわけではないし、俺はでんぱ組.inc含めディアステージのアイドルに詳しいというわけでもないので、言及はしないです。

正式に発表されましたね。

アイカツ!ミュージックフェスタにも参加されてたようなので、コンテンツを支えてくれそうでよかったなあ。


今後のアニメとDCDのスケジュール想像

いろいろな情報が含まれていたのでここからは、俺の完全に妄想になりますが、今秋までにアニメと、DCDどのような感じで行われていくのかを考えてみました。

想像する内容としては、
■アニメ

  1. アイカツオンパレード!』最終回から『アイカツオンパレード!ドリームストーリー』第1話までの1時間スペシャル扱いになる?
  2. アイカツオンパレード!ドリームストーリー』については1クール12話の作品になる?
  3. アイカツオンパレード!ドリームストーリー』後については、新シリーズのアニメではなく、過去のベストシーンの放送か、総集編のようなものが放送される?

■アニメ

  1. DCD『アイカツオンパレード!ドリームストーリー 第3弾』まで実施する?


1時間スペシャルはおそらく確定で実施するのかなと思います。
何らかの形でYouTubeでやっているということを知ってもらいつつ、誘導する必要があると思います。
そのため、これは確定かなと思います。

アイカツオンパレード!』最終回内でどの程度『アイカツオンパレード!ドリームストーリー』に続くような終わり方になるのかはわかりません。


アイカツオンパレード!ドリームストーリー』の放送話数については完全に妄想です。

毎週表記もないので、不定期で放送して今秋(おそらく9月新番)につなげる可能性もありますが、その場合、決算短信の2Q(7月~9月)の売上に影響があるのかなと思うので、不定期はないのでは?と想像します。

ただ、過去総集編みたいな形にした場合、DCDの目玉イベントに影響がありそうなので、本当にそうなのか?みたいな気もします。


DCD『アイカツオンパレード!ドリームストーリー 第3弾』は稼働期間の傾向的にかなり怪しいかな(妄想が外れる可能性が高い)と思います。

基本的にDCDの新バージョンの稼働は60日前後が多いです。
そして稼働日は月末~月初であることが多いので、それを含めて考えた場合に33日とかなり少ないので、第1弾~第2弾の期間が長いのでは?と考えます。

そうなった場合、第1弾は『アイカツオンパレード!ドリームストーリー』12話のイベント、第2弾はそれ以降のアニメに関連したイベントになるのかなと思います。

その妄想を絵にしたのがこの図になります。
f:id:snofra:20200309153859p:plain

f:id:snofra:20200309153932p:plain

最初にも書いた通りこれは俺の完全な妄想に過ぎないので、あてになりません。

*1:19時前にお漏らししていたので、5分前にはすでに内容分かってしまったというトラブルはありましたが

*2:結局2期はテレビ放送するので、振るわなかったという判断も見ることできるけど

*3:DCD『アイカツオンパレード! 第1弾』は2019年10月3日稼働開始で終了まで63日間稼働。DCD『アイカツオンパレード! 第2弾』は2019年12月5日稼働開始で終了まで56日間稼働。

Amazon EBS/インスタンスストア/EFSについて勉強

AWS 認定ソリューションアーキテクト – アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。

今回もこの本を一読したうえで機能単位で勉強していく。


Amazon EBSとは

EC2インスタンスにアタッチして利用する永続可能なブロックストレージサービス。
ブロックストレージとは、データをブロック単位で分割して保存する方式。

www.atmarkit.co.jp

OSやアプリケーション、データ格の場所などの用途に使われる。

スナップショット機能が使えるので、EBSをバックアップしたいときやディスクの暗号化を実施したいときにも使用できる。

EBSはEC2と同一のAZ内でのみアタッチができるというのが注意。
もし、別のAZやリージョンのEC2にEBSの情報を使用させたいという場合、SnapshotをS3に取得し、そこから復元することで対応が可能。


高可用性

Amazon EBS ボリュームは、高い可用性と信頼性を実現するように設計されています。Amazon EBS ボリュームのデータは、追加料金なしで、同じアベイラビリティーゾーン内の複数のサーバーにレプリケートされます。これは、コンポーネントの 1 つに障害が発生したことが原因でデータが失われるのを防ぐためです。詳細については、Amazon EC2 および EBS のサービスレベルアグリーメント (SLA) を参照してください。
特徴 - Amazon EBS | AWS

複数AZ内で複製されるので、単一のディスク障害を回避することができる。また障害を見越した冗長化AWSが実施てくれるため不要。

ただしあくまでも単一AZ内の話なので、AZ自体の障害が起きた場合は復旧できない可能性がある。
そのため定期的にスナップショットを取ってバックアップをとるのがよい。


EBSをマウントする

f:id:snofra:20201204231621g:plain
Amazon EBSを活用してデータをバックアップしてみよう ~Amazon EC2/S3環境構築のすべて~ (2/6):CodeZine(コードジン) より引用

  • EBSボリュームを作成する
  • EBSボリュームをEC2にアタッチする
  • ファイルシステムを作成する
  • EBSボリュームをマウントする


EBSボリュームを作成する

そのまま。EBSボリューム自体を作成する。
ボリュームタイプやサイズを指定する。


EBSボリュームをEC2にアタッチする

作成したボリュームをアタッチ(取付)する。EC2は停止されていなければならないので注意。


ファイルシステムを作成する

EBSボリュームを使用可能の状態にする。


EBSボリュームをマウントする

Q.EBSインスタンスをEC2インスタンスにアタッチする場合、マウントと同じではありませんか?さまざまなガイドによると、彼らは異なることをします。 EBSインスタンスのアタッチとマウントの違いは何ですか?

A.ボリュームをアタッチすると、単にボリュームがブロックデバイスとしてインスタンスにアタッチされます。このアクションは、デバイスオペレーティングシステム内でのみ表示されるようにします。

それを使用するには、フォーマットし、ファイルシステムにマウントする必要があります。マウントは、WindowsよりもLinuxで頻繁に使用される用語です。 Linuxでは、実際にmountコマンドを使用して、デバイスファイルシステム内のポイントに割り当てています。 Windowsでは、ディスク管理を介してボリュームにドライブ文字を割り当てます。
amazon-ec2 - アマゾンec2のebsのアタッチとマウントの違いは何ですか - ITツールウェブ

ハードをくっつけるだけみたいなのがアタッチ。
中身をくっつけるのがマウント。


スナップショットによるバックアップ

スナップショットを用いてS3にバックアップすることができる。

スナップショット実施時はデータ整合性を担保するために静止点を設けることが推奨されている。
ただ、実際は推奨なのでやらなくてもよい。(アプリを停止やEBS自体のアンマウントなどは運用時において現実的ではないので、夜中など処理が発生しないタイミングで実施する形になる)

取得の実行タイミングのものが保管され、完了までEBSが使用できないというようなダウンタイムは発生しない。
バックタイミングは実行タイミングの時点のものとなるため、処理中に追加されたものについては更新されないので注意。

スナップショットは初回はフルバックアップだが、以降は増分バックアップ
1世代目はフルバックアップして、2世目でそこからの増分をバックアップするが、2世代目は1世代目のフルバックアップも保持している状態となる。
そのため1世代目を削除してしまっても問題がない。


www.backstore.jp

スナップショットはプロックレベルで圧縮されるため、課金はその圧縮サイズによって課金されるため、スナップショットの作りすぎは課金の原因となるので、削除するなども検討する。

スナップショットで保存できる世代数や保存期間などはAWSでは設定していない。
そのためスナップショットの世代管理などを行いたい場合は別途考慮する必要がある。


スナップショットを自動化する

Amazon Data Lifecycle Manager を使用して、Amazon EBS ボリュームをバックアップするスナップショットの作成、保持、削除を自動化できます。スナップショット管理を自動化すると、次のことが可能になります。
・定期的なバックアップスケジュールを実施して貴重なデータを保護する。
・監査担当者または社内のコンプライアンスが必要とするバックアップを保持する。

・古いバックアップを削除してストレージコストを削減する。
Amazon CloudWatch Events と AWS CloudTrail のモニタリング機能と組み合わせることで、Amazon Data Lifecycle Manager は EBS ボリューム用の完全バックアップソリューションを追加コストなしで提供します。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/snapshot-lifecycle.html

dev.classmethod.jp

通常、スナップショットは手動で取得する必要があるが、運用時の障害発生時の切り戻し作業などで毎週X曜日のバックアップを取るほうが良い。
どのように対応するのかというと、Amazon Data Lifecycle Manager (DLM)を使用することでスナップショットを取るのが良い。無料。

AWS Backlupを使用してもいいが、他のサービスと含めて一元管理するときに使用するのがよさそう。


スナップショットとAMIの違い

スナップショットも、EC2のAMIもどっちもEBSボリュームのバックアップを実施する。
そのため、どっちを使用すべきかという点がある。

AMI:EC2インスタンスのOS設定などをイメージして保存して新規インスタンス設定に転用。つまりOSなどの情報+EBSの情報となる。
この情報を使用して他のリージョンやAZに新規でインスタンスをセットアップしたいという場合に活用できる。

スナップショット:EBSのその時点の情報をバックアップする。ストレージ自体の復元や複製に使用できる。


EBSのボリュームタイプ

SSDとHDDでそれぞれ複数のボリュームタイプを持つ。


汎用SSD

デフォルトで提供されるストレージタイプ。

ユースケースは、以下のような感じ。

  • 仮想デスクトップ
  • レイテンシーが低いアプリケーション
  • 小中規模のデータベースサービス
  • 開発・テスト環境
  • 負荷が読めないシステム(汎用SSDはバースト機能を持っているため)

上記は主に高性能なI/Oを求めていないときに使用するものとなる。
SSDを安価に利用することができるのが特徴。

最小IOPSは100~最大は16,000まで。
サイズは1GB~16TBまで。


プロビジョンドIOPS SSD

高パフォーマンスを実現できるストレージタイプ。

ユースケースは、以下のような感じ。

  • 大規模なRDBSの構築(高速データ処理を求める場合)
  • 持続的なIOPSが必要なアプリケーションを使用する場合
  • 高いIO性能を求めるNoSQLやアプリケーション

SSDをベースにユーザが自由にIOPSを設定して利用できる。
主に汎用SSDよりも高いパフォーマンスを求められる時に利用。
ただしコスト面で、ストレージ要領+指定したIOPSに対しても課金される。

最小IOPSは100~最大は32,000まで。*1
サイズは4GB~16TBまで。


スループット最適化HDD

HDDタイプのストレージタイプ。
シーケンシャルアクセス時に高い性能を発揮する。長いスループットを使用するビッグデータ解析などに活用できる。

ユースケースは、以下のような感じ。

  • ビッグデータ分析
  • DWH(データウェアハウス)
  • 大規模なETL処理やログ分析

サイズは500GB~16TBまで。
最大500IOPS。


コールドHDD

スループット最適化HDDの高いシーケンシャルアクセスが不要な場合に使用される。

ユースケースは、以下のような感じ。

ログデータなどは基本的にS3に保持するので、どうしてもS3に保存できない場合などに考慮される。

サイズは500GB~16TBまで。
最大250IOPS。


EBSの暗号化

EBSボリュームを暗号化(AES-256)すると、ボリューム内の保持データ、インスタンス→EBSボリューム間で通信されているデータ、スナップショットすべてが暗号化される。

暗号化(復号化)はハードウェア機能で実施されるため、パフォーマンス影響はかなり小さく済む。
そのため、暗号化の時間とかは設計時に考慮不要。

暗号化したスナップショットを使用して、EBSを復元すると暗号化したままなので安心。


AWS KMSを利用したKEYの生成

EBSボリュームを作成する際にAWS KMSを使用して、ボリュームを暗号化するオプションがあるので、それを利用する。
snofra.hatenablog.com

暗号化された Amazon EBS ボリュームを別の AWS アカウントと共有するにはどうすればよいですか ?

1. Amazon EBS スナップショットを作成します。
注: EBS ボリュームがインスタンスにアタッチされている場合は、データの整合性を確保するために インスタンスを停止 します。
2. 次の AWS Key Management Service (AWS KMS) キーポリシーの例を使用して、暗号化されたスナップショットを共有 します。
3. 共有スナップショットのコピーを作成します。詳細については、スナップショットをコピーする を参照してください。
注: 必ず AWS アカウントのカスタマーマスターキー (CMK) を選択してください。そうしないと、デフォルトのマスターキーが使用されます。
4. スナップショットから EBS ボリュームを作成します。詳細については、スナップショットからの Amazon EBS ボリュームの復元を参照してください。
注: スナップショットは、スナップショットが作成された AWS リージョン でのみ復元できます。別のリージョンの EBS ボリュームの場合は、最初にそのリージョンにスナップショットをコピーしてから、スナップショットを復元します。

dev.classmethod.jp


上の情報からも単純にスナップショットを取るだけでは不足している。KMSを利用することになる。

また別リージョンに持っていくことは可能だが、リージョンにスナップショットをコピーが必要。


後からEBSを暗号化したい場合

EBSボリュームを後から暗号化したい場合は、スナップショットを作成しなければ変更できない。

  1. スナップショットを取得
  2. 暗号化を有効にしてスナップショットをコピー
  3. コピーしたスナップショットで復元
  4. 新しいEBSボリュームをEC2インスタンスにアタッチする

スナップショットを取って、さらにそれをコピーするのが必要。


EBS最適化インスタンス

EBSのパフォーマンスとして、EBS最適化の設定を選択することでEC2とEBS間の専用通信帯域を確保することができる。


f:id:snofra:20200302232459p:plain
EBS最適化インスタンスの効果を知るべくベンチマークを取ってみた | Developers.IOより引用


インスタンスストア

EC2のインスタンスで利用できる無料のストレージサービス。
EC2のホストコンピュータ上にのっているストレージなので、パフォーマンスはよいが揮発性ディスクなので、インスタンスを停止すると情報が消える。

高パフォーマンス+可用性を求める場合、インメモリーキャッシュのAmazon ElastiCacheなどを利用する。


Amazon Elastic File System(EFS)

複数EC2インスタンスからアクセス可能な共有ストレージ。
具体的には、複数EC2からNFSNFS v4.0/4.1)を使用して、ネットワーク経由でアクセスするものとなる。

ファイルシステム当たり最大 2GB/秒のスループット、数百万の IOPS、一貫したミリ秒未満のレイテンシーという高速パフォーマンスが実現可能な高性能なストレージ。
(EFSよりもIOPSという面で優れているのも特徴)

NFSなので、Windowsのファイル共有サービス(SMB)ではないことに注意Windowsのファイルサーバーを使用したいのであれば、Amazon FSx for Windows を利用する。
www.designet.co.jp

ファイルシステムなので、ファイル単位でのアクセスとなる。
ルートディレクトリ(ファイルシステム)とその配下のディレクトリあってその中にファイルがある。

EC2だけではなく、オンプレミスサーバーからも利用できるのが特徴。
ストレージ要領やパフォーマンスを自動的にスケーリングすることもできる。

ユースケース

主にいかような場合に利用される。

  • S3で対応できないリアルタイム更新したい場合でのアプリケーションの共有ディレクトリとして利用
  • ビッグデータなどの分散並列処理を実行する環境におけるデータアクセス用のストレージとして利用
  • AutoScalingするWebサーバ群がアクセスする、ユーザーがアップロードした画像ファイルなどコンテンツの共有リポジトリとして利用

上記のようなEBSではできない複数インスタンスからの同時アクセスや、S3のような長期保存ではなく秒単位でデータが追記されるケースでの活用が考えられる。


高耐久性・高可用性

Amazon EFS では、複数の AZ 間で自動的にデータをレプリケートします。自己管理型クラウドソリューションでは、AZ 間のレプリケーションのためにストレージ容量を追加する必要があり、さらに AWS AZ 間でデータを転送するためにコストが発生します。Amazon EFS の場合、このようなコストは 1 か月あたり 0.30 USD/GB の料金に含まれています。
総所有コスト - Amazon EFS | AWS

自動で複数AZ間で複製して保存する点や、複数AZの複数EC2インスタンスから読み書きできる。
また、読み取り整合性も強力で、書き込み完了直後に即時反映されている。
(S3はデータ整合性モデルのため書き込み直後に反映していないケースがあるのでそれを比べても有用)
※ロックはファイル単位・バイト範囲単位

データの保護

EFSは耐久性が高いことは分かったが、バージョニングができない。そのため、オペミスをしてファイル消しちゃったみたいな場合にはEFS単体ではどうしようもできない。

データ自体の保護はAWS Backup サービスでデータを保護できる。

docs.aws.amazon.com

EBSのようにスナップショットを取得することはできない。

セキュリティ

EC2とEFSの間にはマウントターゲットという接続先が存在する。
同じAZのインスタンスは同じマウントターゲットに接続する。

f:id:snofra:20201126231722p:plain

このマウントターゲットに対し、セキュリティグループを設定することが可能。

またネットワークACLでサブネット単位でアクセス制御も可能。


パフォーマンス

EFSには二つのモードが存在する。

  1. 汎用モード
  2. 最大I/Oモード


汎用モード

一般的な用途を想定したモード
ファイル操作のレイテンシーが低いが、1秒あたりのファイル操作回数が7000に制限されている。
大体はこれを選択する。


最大I/Oモード

何十~何千単位の大規模なクライアントから同時アクセスされる構築で使用する。
仮想的に無制限にスケールアウトできるスループットとIOPSであるが、レイテンシーがわずかに長くなる。


バースト機能

ファイルストレージの以下のような負荷に対して一時的に性能を向上させる機能。

  • NFSサーバー容量増大に応じたスループット性能の拡張
  • 一時的なピーク時の負荷が増大する可能性がある場合

制限事項

  • アカウント当たりのファイルシステム数:1000
  • AZごとのファイルシステム当たりのマウンスターゲット:1
  • ファイルシステムあたりのタグ数:50
  • マウントターゲットあたりのセキュリティグループ:5
  • ファイルシステム当たりのVPC数:1
  • VPC内でのマウントターゲットの数:400
  • インターネット、インターネットVPN、インターリージョン(リージョン間)VPC Peeringからアクセスはできない
  • バックアップ機能、バージョニング機能は未提供

インターネット、インターネットVPN、インターリージョン(リージョン間)VPC Peeringからアクセスはできないという点がポイントになる。
またDirect Connectからはアクセスすることが可能。


EFSマウントヘルパー

マウントヘルパーとはEFSを簡単にマウントすることができる機能です。
この機能は、AWSが公開しているamazon-efs-utilsというパッケージを導入することで使うことができます。
Amazon Elastic File System(EFS)を使ううえでの勘所 - Qiita

Amazon EFS は、ファイルシステムの 2 つの暗号化形式、転送時の暗号化と保管時のデータの暗号化をサポートします。Amazon EFS ファイルシステムを作成する場合、保管時のデータの暗号化を有効にすることができます。後でファイルシステムをマウントする時、伝送中のデータの暗号化を有効にすることができます。
https://docs.aws.amazon.com/ja_jp/efs/latest/ug/encryption.html#encryption-in-transit

マウントヘルパーを使用せずに、stunnelを利用することで転送中のデータの暗号化を有効にすることが可能だが、作業が必要なので基本的にはマウントヘルパー安定

dev.classmethod.jp

EFSに似たファイルストレージ

EFS以外にも似たファイルストレージサービスが存在する。
これらはオンプレミス型と互換性のあるファイルストレージとなる。


Amazon FSx for Windows ファイルサーバー

Windowsファイルサーバーと互換性のあるストレージ。(SMBプロトコル
Windowsファイルサーバーをオンプレ→クラウドに移行したい場合などに利用される。

f:id:snofra:20201127000007p:plain
Amazon FSx で簡単に作れる Windows ホームディレクトリ | Amazon Web Services ブログ より引用

Windows上に構築され、Windows Active Directoryを使用できるので、現状利用している場合などに便利。


Amazon FSx for Lustre

スーパーコンピュータに領される分散ファイルシステム
高速コンピューティング処理を実現する分散・並列処理専用の超高性能ストレージを提供している。

EBS vs インスタンスストア vs EFS

f:id:snofra:20200302232249p:plain

ポイントはひとつのEBS/EFSが何台のEC2に接続できるかという点。

〇EBS
EC2から見るとEC2:EBS=1:Nで接続、つまりひとつのEC2に対し複数のEBSを接続できる。
EBSから見ると、EBS:EC2=1:1となる。ひとつのEBSは、ひとつのEC2にしか接続できない。
*2

〇EFS
EC2から見るとEC2:EFS=1:Nで接続、つまりひとつのEC2に対し複数のEFSを接続できる。
EFSから見ると、EFS:EC2=1:Nとなる。ひとつのEFSは、複数のEC2に接続できる。

また、ひとつのEC2インスタンスに対しEBSとEFSを組み合わせてアタッチできない。
(EBS+S3やECS+S3、EBS+ECSはできるらしい)

*1:Nitroベースインスタンスでは64,000IOPSまでだせるらしい

*2:日本リージョンにまだ来ていないがプロビジョン度IOPSボリューム上でEBSが複数アタッチできるようになった。https://aws.amazon.com/jp/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

NATゲートウェイについて勉強

AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。

今回もこの本を一読したうえで機能単位で勉強していく。


NATゲートウェイとは

プライベートサブネット上に存在するEC2やRDSは、情報の剽窃や改ざんなどを防止するためにインターネットから接続ができないようになっている。

インターネットから接続ができないということは、外部から接続できないのと同時にプライベートサブネット内部からも接続できない。

ただ、それだとEC2に乗せているパッチ更新などもできなくなって不便になるので内部からはインターネットに接続できるようにさせるためのもの。

https://image.slidesharecdn.com/20190313aws-blackbelt-vpc-190313090341/95/20190313-aws-black-belt-online-seminar-amazon-vpc-basic-81-638.jpg?cb=1552471200*1


単純にインターネット接続以外にも、S3やDynamoDBのようなリージョンサービスを利用するためには、VPCエンドポイントを利用しない場合はインターネットアクセスをするのでそのために外に出られるようにしなければならない。
f:id:snofra:20200301232511p:plain*2

上の図であるように基本的にパブリックサブネット上に立てる。
高可用にするためには複数のアベイラビリティゾーンに設置するのがよい。


NATインスタンス

NATゲートウェイと同様の役割として、NATインスタンスがある。
これは単純にNAT扱いのEC2インスタンスというだけ。

NATゲートウェイとの細かな違いは以下を参考。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-comparison.html

NATインスタンスのメンテナンス自体は自分でやる必要があるので、単一障害点になりやすいので注意する。
(可用性を上げるのであればNATゲートウェイにするという問題がある)

アイカツオンパレード!ライブ ユニパレ!の中止が発表されました

2月入ったあたりからちらほら聞くようになってきたコロナウィルス。
ついに今日、2週間のイベントの自粛要請が発表されて*1アイカツオンパレード!ライブ ユニパレ!』がどうなるか心配でならなかったけどついに中止が正式に発表された。

俺はチケットがご用意されなかった問題で、3月8日金曜日のみの参戦だったがすごい残念。

罹患しないためには人ごみにいないことで、思いっきり人ごみに数時間いることになるライブは中止になるのは仕方ない。
演者の方が罹患してしまうのは、参加している全員が求めていないことだし、安全を考慮したらそうなるよなあとは思うものの、やっぱり行きたかったなー。

個人的には気合入れて髪色も霧矢あおいカラーにしたので、この髪色どうしようかなっていうのは正直ある。

f:id:snofra:20200227002353j:plain


またみんな元気で集まって盛り上がれたらいいなって


この記事を書いた時点での関係者のコメント

カードゲーム対戦動画を作り始めたので使用機器メモ

去年あたりから修行と称して、隔週で身内と遊戯王の大会(CS)向けのデッキで対戦している。

そもそもこれをやろうと思ったのは、
・俺がもっと遊戯王強くなりたいという気持ちがあった
・私事で土日なかなか時間が取れないが、平日夜なら時間が取れるという状況だった
といいうのがある。

相手は俺よりも少し格上くらいで、始めたばかりのころは全然歯が立たなかったが、最近はマッチ戦で勝利できることもあるのでレベルが上がってきているという感覚が実感できて遊戯王楽しい感がある。

俺の趣味のひとつなので、数ヶ月に1回の対人戦から隔週になったので単純にたくさんやれて嬉しいというのもある。

で、負け試合をもっと分析したいなということもあって、今年から動画を作ってYoutubeにアップロードしている。
身内しか見られないが、1ヶ月程度運用して15本くらい作れているので、まあまあやっているなあという感じ。


どのように動画を作っているのか

f:id:snofra:20200117161915j:plain
こんな感じ

身内向けだし配信のクオリティはあまり気にしなくてもいいのかなーというのもあって、iPhone8で撮影している。
なんでもできるiPhone楽。

カードゲームなのでフィールド全体が移るような画角が必要で、1マッチ30分~1時間程度かかるし、ゲームの仕組み上相手ターンにカードをプレイする必要があるので、ターンプレイヤーじゃない人がiPhoneを持つのはちょっと現実的じゃない。
(昔、遠方の友達向けに配信していた時はターンプレイヤーじゃない人が持つ運用にしたが、手がつかれて面倒なうえに、画角を気にしているとカードのプレイを忘れたりしてあまり良くなかった)

そんなわけで、机の上に置く三脚を買った。


1ヶ月運用していて感じたところを書く。

使っていてすごく困ったことはない

全く使えなかったみたいなことは全然なくて、普通に使えている。

スマホグリップはiPhone8はキレイにはまるので、それよりも小さいサイズははまると思う。
Proみたいな大きいのスマホははまらないかも。


〇分解して折りたためる
脚は折りたためて、支柱部も曲げることができるので分解することでリュックに入れられるのがよい。
(鉄製なので少し重いが)持ち運びもできるので、デッキと一緒に持ち歩いてる。


スマホグリップが360度回る・支柱が折り曲げられる
対戦時はスマホを横持ちの形でセットしている。
また人によってプレイマットマットの大きさも違うので、支柱を曲げて画角を自由に調整できるのもよい。


〇高さが少し不足している
これはまあ仕方ないかなと思うけど、高さが46.5cmということで真上から俯瞰することはできず、斜めから俯瞰することになる。
そのため、画角撮りに失敗すると墓地が微妙に映っていなかったりするのでその辺の調整が面倒だなって思う。

f:id:snofra:20200221102335p:plain
こんな感じで墓地が微妙に映っていない。(手前側)


〇テーブルが揺れるとカメラも揺れる
これがちょっと厄介。
支柱部が曲げられるというのは、安定度が不足しているということなので、デッキや手札をテーブルに当てる(紙を整頓するときにトントンするアレ)と揺れる。
俺はいわゆるシャカパチはしないが、これを癖でこれをやってしまうので、そのたびに揺れてしまう。
見ているときに揺れたなってわかる程度。
まあ俺がその癖を止めればいいって話だが。


〇脚が床と接着していない
これも地味に困る。
脚は床に接着する箇所が4点あるが、3点しか接着しないので、カメラ揺れる問題の原因のひとつとなってしまっている。
とりあえず、100均で滑り止めのシートを買って4点接着するようにしている。



使っていて気になったのはこの辺り。

f:id:snofra:20200117161718j:plain

あとはスマホグリップにiPhoneをセットするとき、支柱部によりも左(右)側にカメラレンズがあるので、三脚を中心に考えると画角がカメラレンズ側に寄ってしまう。

なので、画角調整するときに三脚をカメラレンズがある方向と逆の方向に移動して、カメラレンズが中心にくるように調整が必要。

多分同じような三脚は基本同じような感じだと思う。


iPhoneをカメラとして使用することのいいところ・課題

iPhoneを利用することの一番のいいところは、余計な出費が少ないというところ。
普通にカメラ買うよりも使いやすいし、動画はiCloudからPCに持ってこれるので外部装置を使わなくていい。

画質も音質も悪くない。
(音質は店のBGMを拾いすぎていしまってYoutube上にアップロードする際に著作権侵害の恐れがあるとメッセージが出てしまう程度に拾ってしまう)

ただし、iPhone自体の容量は食うし、充電もかなり消費してしまう。
俺のスマホ固有事象の可能性があるけど、3時間やると充電が10パーセントくらいになる。

また、連続して撮影していると発熱の問題か、充電が20(10)パーセントの時に表示されるダイアログのせいか、録画が止まってしまうことがあった。
だから、マッチ戦でも1回終わるごとに録画を止めている。
(サイドチェンジの時間はどのみち編集で切るし、動画編集するにあたって1マッチよりも1回ずつのほうがやりやすい)


今後もスマホ運用していくと思うけど、三脚は折を見ていいものに変えればいいかなと思う。

Amazon Redshiftで「Serializable isolation violation on table」のエラーが発生した

バッチ処理中にRedshiftでエラーが発生した。

「Serializable isolation violation on table - [数値], transactions forming the cycle are: [数値], [数値](pid:[数値])」

というメッセージ。

原因は単純で1つのテーブルに対し同時に複数の書き込み処理はできないよってエラー。

Amazon Redshift の同時書き込みオペレーションは、直列化可能でなければなりません。すなわち、トランザクションは、同時に実行された場合と同じ結果を出せる 1 つ以上の順序で、直列的に実行可能でなければなりません。詳細は直列化可能分離をご覧ください。
「ERROR: 1023 DETAIL: Serializable isolation violation on table in Redshift」エラーを解決する


Serializable Isolationは直列化可能分離という意味で、開発者ドキュメント上では

Amazon Redshift では、同時書き込みオペレーションはテーブルの書き込みロックと直列化分離を利用して安全にサポートされます。直列化分離では、テーブルに対して実行されるトランザクションは、そのテーブルに対して実行される唯一のトランザクションであるという錯覚が守られます。例えば、T1 と T2 という 2 つの同時実行トランザクションで次の少なくとも 1 つとして同じ結果が生成されます。

・T1 と T2 がこの順序で連続して実行されます。

・T2 と T1 がこの順序で連続して実行されます。

同時トランザクションは互いに認識されません。互いの変更を検出できません。各同時トランザクションにより、トランザクションの始めにデータベースのスナップショットが作成されます。データベーススナップショットは、ほとんどの SELECT ステートメント、COPY、DELETE、INSERT、UPDATE、TRUNCATE などの DML コマンド、次の DDL コマンドの最初の発生時にトランザクション内で作成されます。

・ALTER TABLE (列を追加または削除する)

・CREATE TABLE

DROP TABLE

・TRUNCATE TABLE

同時トランザクションの任意の直列実行でその同時実行と同じ結果が生成された場合、そのようなトランザクションは「直列化可能」とみなされ、安全に実行できます。そのようなトランザクションの直列実行で同じ結果が生成されない場合、直列化可能性を壊すステートメントを実行するトランザクションが中止となり、ロールバックされます。
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_serial_isolation.html

な感じなことが書かれている。


確かに同じテーブルに対して、書き込みをする処理が同時に走っていたのでこのエラーに引っかかっていたのかなーと。