  |
はてなキーワード: オーケストレーションとは
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
ITエンジニアでもソフトウェアエンジニア（というかこの人の場合旧来の「プログラマ」って感じだ）ではなく、インフラ系ならハッタリ効くしゴリゴリの最新技術は求められないよ。
というか、最新技術がだいたい既存の技術を仮想化してオーケストレーションできるようにしました程度なので、キャッチアップがめちゃくちゃ楽だから現時点のスキルはあまり問わない。
7-800程度でいいなら「単に経験が長い」というだけで行けるよ。職務経歴書をちゃんと書けるなら。少なくとも俺の経験上上場企業数社はそれで入れた実績がある。
むしろ小さいとこの方が細かいスキルチェックをしようとしてくる印象があるな。多分人事予算に余裕がないから最大効率を求めるんだろう。
椎名林檎をちゃんと追ってるわけではなかったけど、「女の子は誰でも」をCMで聞いた時にオッと思い、数年後これを聞いてなるほど～～って頭ブンブン振っちゃったね
https://music.apple.com/jp/album/1385322133?i=1385322148
未就学児の当時よく歌っていたらしい(!?) 後になって作者が大物であることを知り驚く
自分はハチ・米津玄師の楽曲に対して、なんでこんなのが流行ってんだよみたいなマジで穿った見方をしてた、これを聞くまでは……
皮肉まみれの歌詞が当時だいぶ物議をかもしてた気がするけど、曲はそんなのどうでもいいくらい、悔しいくらいカッコいい
https://music.apple.com/jp/album/1268503456?i=1268503458
ライブ音源です 21世紀の未来のアイドルがこういう曲で踊ってる(しかもロサンゼルスで)という面白さ
安部潤のシンセはT-SQUAREリスペクトらしい 生で聞けたらどんなに楽しかっただろう
https://music.apple.com/jp/album/642832495?i=642832943
まずメロディでこれはHungry Spider以来久しぶりのダークなマッキーじゃ～んと思って、次に歌詞をちゃんと読んで完全に泣いた 同じ性別の人を好きになった人の気持ちがこんなにもわかるか?
https://music.apple.com/jp/album/548245136?i=548245147
ポップンやってた中高の頃、ゲーム内で気になる曲の作曲者を調べたらことごとくwacだったのがちょっと怖かった
その例外がHomesick Pt. 2＆3 / orangenoise shortcut、と思ってたけど今調べたら編曲にwacが関わってるらしい マジかよ……
https://music.apple.com/jp/album/498158513?i=498158523
配信サービスで後追いで知る(このリストの硝子の少年とプラチナを除く2005以前の曲は全部後追いですが)
音楽サブスクにおけるレコメンドエンジンというのは恐ろしい大発明ですね このあたりの(自分が能動的に音楽を聴く前の)年代のお洒落な邦楽って絶対たくさんあるはずなのでこれからも掘っていきたい
https://music.apple.com/jp/album/1486281113?i=1486281117
あつぞうくん名義(もともとMelting Holidaysというウィスパーボイス・ソフトロック系のユニットをやっていた)での2枚目のオリジナルアルバム「メガネディスコ」の最後から2曲目がこれ 実質的にはこれがトリ
当時インタビューでRoger Nichols and The Small Circle Of Friends、The 5th Dimention、ピチカート・ファイブに影響を受けたと書いてあるのを見て、それぞれ聞いてみると3グループ全部が自分の好みであったことから、いわゆる渋谷系とその"元ネタ"という概念にハマるきっかけとなる
https://music.apple.com/jp/album/1565906466?i=1565906478
原曲（sm12173659）は非公開・配信無し・CDも入手困難となっていたのですが、2021年に新録されたリアレンジ版がコンピに収録されサブスク配信されています これも良いんですけどどうにかして原曲も聞いてみてください
今考えると初音ミクの登場から数か月という段階(メルト以前!)でこんなに完成されたスキャットが出てきたことが本当に恐ろしい…… オーパーツですか?
OSTERのオリジナルアルバムに何度もリアレンジ・リミックスが収録されたり(ほとんどがアルバムの最後もしくはそれに準ずるような場所に入ってる 曲順が解釈一致ですありがとうございます)、令和の時代になってもゲームでカバーされたり、公式/公認だけでも数えきれないバリエーションが存在する
歌い継がれてほしい
https://music.apple.com/jp/album/662012326?i=662012451
配信で聞けるのはベスト盤向けセルフリミックス(↑)(※Spotifyには無い)、プロセカ(ワンダショ)のカバー(Spotifyで聞くならこれ)、PSBハヤシベトモノリによるリミックスのみ
渋谷系ニワカのときにたくさん買ったCDの中にあった ベストアルバム「PIZZICATO FIVE JPN」の最後の曲だった
攻撃的なリズム隊! 荒ぶるストリングス! キラッキラしたブラスセクション! 淡々と歌う2人! 最高～
Don't Take Your Time元ネタの楽曲は全部好きだけどこれは別格
ここまで楽しくて悲しい曲は聞いたことがない
https://music.apple.com/jp/album/1484037087?i=1484037108
1作曲者につき1曲縛りとした
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
5chに連投コピペで貼られてたんだけど、ググっても元の文章が出てこない。
・すぎやまこういち（1931年東京都生。作曲家。日本バックギャモン協会会長）
・植松伸夫（1959年高知県生。神奈川大学外国語学部英語科を卒業後、TVCM等フリーで活躍し、1986年スクウェア入社）
（要約）
すきやま：
だんだんドラクエ関連のスケジュールだけで１年終わっちゃうみたいな有様になってきちゃって、
あんまり他のことができなくなってきてるんだよね。困ったもんだよ。
ドラクエやると、やれCDブックだアニメだときて、レコードもブラスバージョンやエレクトーンバージョンやピアノバージョンが出て、
そうなると色んな出版社がピアノ譜やエレクトーン譜を出す。そんなことやってるから1年潰れちゃうもんね。
植松：
すきやま：
どうしても大変だと思いながら、「このゲームが好きだなあ」ってことになるとついね。
植松：
まさか本当にやって頂けるとはね。言ってみるもんだなとつくづく思いましたよ（笑）
すきやま：
でも楽しかったね、あれは。FFVも大変だったね。やっと僕も上がったんですけどね。
植松君は働き者だなとつくづく思いましたよ。何曲あるの、あれ？
植松：
60近くはあるかもしれないですね。
すぎやま：
60曲あのゲームの中にあるということは、実際作った曲はその裏にもっとあるでしょう。何曲ぐらい？
植松：
1コーラス作ったという感じで言ったら100曲ぐらいいってるかもしれないですね。
すぎやま：
働き者だなあ（笑）
植松：
曲数が多いというのも一既にいいとは言えないとも思ってるんですよね。
すぎやま：
植松：
そんなでもないんですけどね、それでも10曲ぐらいは少ないかな？
すぎやま：
そうでしょ。やってる時はこの曲面白いなと思うんだけど、終わったあと覚えてる数が少ない感じがしたね。
その原因は何だろうと思ったんだけど、多すぎるというのがあるのかもしれないな。
でもやっぱりどんどん意欲が湧いて、ここはこういう曲にしちゃおう、ここはこうしようっていうのが出てきちゃうものだよね。
植松：
作ってる方としてはまだ足りないんじゃないかという気もするんですよね。完成したあとに自分でやってみますよね。
そうすると、こことここの音楽変わってないやっていうところがいくつかあるんですよ。
だから作った本人は全部曲覚えてるから別に問題ないんですけど、
自分以外の一般の人にとっては多いかなとは思ってるんですけどね。
30曲に抑えようとしたんですよ。IVのときもちょっと多いと思ったんです。
今回は絞り込んでやろうと思ってたんですけど、欲が出てしまいますね。
すぎやま：
僕も曲を絞り込むときは断腸の思いでね。切る作業が大変ですよ。
前にも言ったと思うんだけど、むこうのミュージカルなんかを見ると本当に曲数少ないんだよね。
でも植松さんのやり方でいいなと思うのは、1つの曲をシーンに応じてアレンジを変えて出すケースが多いでしょう。
植松：
すきやま：
働き者なんだよ。FFVの曲は植松さんの趣味趣向がはっきり出てるから、
それがある意味でいい個性になってていいなというのがありますね。
スコットランド民謡をはじめとして、民族音楽への傾斜というのがあるでしょ。
植松：
今回そのアイルランドのリールっぽい曲を入れたのって初めてなんですけど、あれを入れますと
ユーザーの意見なんかのハガキに「アイルランド行ってきて帰ってきたらもうこれだ」というのがあるんですよ（笑）
別にアイルランドから帰ってきて、その影響受けてやってるわけじゃないんですけど。
以前から凄く民族音楽に興味がありまして、入れたかったんですけどファミコンのときとかって難しいじゃないですか。
すぎやま：
ちょっとやりにくいよね。
植松：
いつかやってやろうと思ってたんですけど、あんまり興味本位で民族音楽好きだから
入れるというのも安っぽく見えてイヤかなと思ったんですけどね。
先日、すぎやま先生がうちの職場にいらした時にお話ししたんですけど、今トルコ音楽を習いに行ってまして、
すぎやま：
植松：
日本人だったら日本の音楽ルーツとして民謡とかがあるはずだと思ってるんですよ。
日本に昔からある音楽が自分の血の中にあるはずだって自分では思ってるんですけど、
一度「雅楽（古来の宮廷音楽の総称）」の“ひちりき”（雅楽用の竹製の管楽器）を習いに行ったことがあるんです。
そうすると自分の中に流れている血というよりも、逆にそれがすごく新しい、
ブライアン・イーノのシンセサイザーの音楽に近い印象があったんですよね。
すぎやま：
笙（雅楽用の管楽器）のハーモニーなんかは音の響きが非常にシンセサイザー的な新しさがあるよね。
植松：
そうなんですよ。だからこれはものすごく面白いけど、自分にとっての血ではない気がしたんですよ。
雅楽は朝鮮からのものですけどね、そういうルーツみたいなものを考えていったら、
逆にヨーロッパの民族音楽がすごく自分にピンとくるものがあったんです。
自分にとってピンとくるものを追っかけていく方が面白いんじゃないだろうかと思って、
最近は自分が日本人だから日本古来の音楽をどうのこうのという考えはなくなってきてるんですよね。
すぎやま：
僕ら日本人で日本の文化の中で暮らしていると、いつかは三味線音楽や琴の音楽が耳に触れてるわけ。
和風喫茶やレストラン、エアラインなんかでもいつの間にか聞こえてくる。
アメリカで生まれ住んでるとそれは耳に触れないで大人になっちゃうでしょう。
僕らは耳に触れてるから、知らない間にそういう音感は身についてると思うの。
町の音楽「ミーファー」ってメロディがいくときに、もう1つの声部が「ミーミー」とそのまま引っ張って、
ミとファが平気でガチャーンと使ってるのがあるでしょう（トゥールの村などの音楽）。
植松：
バッテンなんですよね。
すぎやま：
植松さんはあれにある種の美しさを感じるからやってるわけでしょう。
で、僕も日本人だから聞いて「あ、ここいいな」と思ったんですよ。
「ソーミーファー」というのと「ソーミーミー」というところでミとファがぶつかっているのは、
西洋音楽のエフメジャーセブンの中のミとファのぶつかりの意味とは全然違う意味のミとファでしょ。
それは江戸時代の三味線や琴の音楽でしょっちゅうやってることなんだよな。
「ラファミミファミミファファミ」といってるときに、1は「ミミミ」といってミとファがぶつかってるという、
そういうテンションに美しさを感じるという江戸時代の音楽家らの伝統みたいな感覚の流れがあるんだよね。
あの部分を聞いて植松伸夫もやっぱり日本人だと思ったんですよ。
で、僕もアレをイヤだと思わずに、あぁこれいいなと感じて、僕も日本人だなと再確認したんです。
植松：
ミとファの半音でメロディと伴奏が平気でぶつかることがしばしばあるんですよね。
自分でもああぶつかってるな、クラシックの音楽のテストなら絶対にバツだなと思っても、
その響き欲しいしと思ってそのまま残すこともあるんですよ。
すぎやま：
それが間違いか間違いじゃないかというのは、感覚的にそのぶつかりが許せるかどうかなのよ。
いいと思うかどうかなのね。だから西洋音楽なんかも近代音楽以降はガンガンぷつかるでしょう。
それが前後の関係や音楽全体の姿からいって、感覚的にこれが美しいと思えるものはマルなのね。
ミとファのぶつかりあいが美しいと思える感受性があってやったものであれば間違いじゃないんだよ。
ただそれが自分一人でいいと思ってるだけで、世の中全員が気持ち悪いと思ったら
植松：
難しいですよね。音楽を学問にした人というのは、かなり強引だと思ってるんですよ。
どうやって音楽の点つけるんだろうって未だに僕思ってるんですよね。
小中学校を通して音楽というものを学校の教育に取り入れて100点取った人は偉い、
大人になって楽器を手にしなくなっちゃう人が多いんじゃないでしょうかね。
すぎやま：
音楽教育というのがどうあるべきかというものは、これはもっと考えなくてはいけない問題で、
植松：
すぎやま：
笛を吹いたことについて点数つけることよりも、笛吹く楽しさをわからせるのが大事だよね。
だからファイナルファンタジーとかドラゴンクエストの音楽というのは大事なんですよ。
植松：
ドラゴンクエストの音楽が好きになってコンサート行きますよね。
すぎやま先生なんかのコンサートはフルオーケストラでやってらっしゃるでしょう。
それはものすごい影響力だと思うんですよね。
子供がオーケストラを生で聞くチャンスが普段あるかというと、少なくとも僕は子供の頃そんな経験はしてないんですよ。
そうすると、ある意味ですごく羨ましいんですよね。小学校2-3年という頃に、N響の音が年に1回、生で聞けるわけでしょう。
すぎやま：
他のオケなんかのコンサート数えると、20-30回やってるよ。全部ドラクエじゃないにしても、1コーナーとかね。
だから、あちこちに頼まれて棒振りに行く仕事もやってます。それは大事なことだからね。
植松：
すぎやま：
しかし、いつもゲームの音楽作るときに、昔の大作曲家の作品聞くじゃない。
とてもかなわないなと思うことが多いね。
植松：
すぎやまさんがそんなこと言ったらこちらの立場はどうなるんですか（笑）
すぎやま：
昨日久しぶりにバレエ見ようと思って神奈川県民ホールに「くるみ割り人形」見に行ったの。
チャイコフスキーのド天才めって感じだよ（笑）。とんでもない天才だね。
植松：
チャイコフスキーは僕もすごく好きですね。音楽は誰が好きなんですかなんてインタビューとかであるじゃないですか。
すぎやま：
とんでもない大天才だよね、あの人は。
あの時代で20世紀の音楽家が考えて書くようなヴォイシングやってたりするわけよ。オーケストレーションのうまいこと。
植松：
この前、西田敏行がロシアに行ってチャイコフスキーの足跡を辿るという番組をテレビでやってたんですよ。
僕もチャイコフスキー好きだから見てたんですけど、チャイコフスキーはホモであるというのを聞いて、
「ああ良かった」と思ったんですよね（笑）
すきやま：
その良かったというのはどういう意味なの？
植松：
チャイコフスキーも人間だったんだなというね。ま、噂なんですけどね。
すきやま：
モーツァルトなんか完全にいってるよね。大天才でも大欠点があるという。
植松：
チャイコフスキーにしろモーツァルトにしろ、メロディが非常にわかりやすいんですよね。
クラシックって難しいから嫌いという人が多いですけど、そんなことないと思うんですよ。
すきやま：
ベートーベンとかブラームスあたりはみんなそうだよ。いいメロディもってるよ。
植松：
すぎやま：
植松：
だからドラクエなんかはオーケストラでやっても子供が聞けるんですよ。
すぎやま：
ドラクエにしてもFFにしてもメロディ大事にしてるからそこに強みがあるでしょう。
他にもFFでは民族音楽的なのがありましたな。デデンッデデンッ…てやつ（笑）
植松：
すきやま：
だからそのうちトルコも出てくるぞ（笑） FFでは吟遊詩人というジョブがあるじゃない。
吟遊詩人がマップの中のトルコやアイルランドみたいなところへ行ったりするとそこの音楽を覚えて、
それを戦闘中に唄うと何かが起こるみたいなことがあれば面白いんじゃない。
植松：
すぎやま：
増えるね（笑） でも吟遊詩人というジョブがあるから使えそうな気もするね。
植松：
一度何かに絡めてやってやろうと思ってるんですけどね。
どうしても容量がそういう余分なところまで回らないんですよ。
すぎやま：
植松：
すぎやま：
ダンジョンも違う？そんな気もしたんだけど。
植松：
いや、ダンジョンという曲は1曲しか用意してないんですよね。他で使ってるのを使いまわしてるんです。
すぎやま：
でもなんかすごく多い気がしたな。
植松：
実際多いんですよね。飛空艇は1曲ですし、チョコボは2曲だし。
すぎやま：
チョコボはまた面白いね。あの音楽と動きを見事にシンクロさせてて良かった。
植松：
あそこらへんはプログラマなんかと楽しんで作ってましたよ。
すぎやま：
植松：
ヘタクソなやつが最後はコンサートピアニストぐらいにしてくれと言われたんで、
最初はメトロノームにも合わせられないようなところから始めて、最後はドビュッシーまで弾けちゃうんですけど、
あのドビュッシーの曲（月の光）をみんなあんまり知らないんで、ガッカリしちゃったんです。
すぎやま：
グリークとかチャイコフスキーのピアノコンチェルトみたいな方がコンサートピアニストみたいな気がするからね。
植松：
そうですよね。最後のが弱かったのが残念だったな。
すぎやま：
植松：
息抜きというやつですね。でも結構一生懸命やっちゃうんで、息抜きできなくなっちゃうんですけど。
すぎやま：
作ってる本人はいいんだよ。遊ぶ方は息抜きできるんだから。植松さんはドラクエは上がったの？
植松：
実は最後のダンジョンの手前でFFVのアレンジCDの仕事に入っちゃいまして、まだなんですよ。
すぎやま：
上がってないの！？
植松：
今日までに終わらせるつもりだったんですけど。
すぎやま：
僕は対談頼まれたときに、12月中だと聞いてそれまでにFFVを終わらせる自信ないって言ってたんだけど、
元祖プロゲーマーを称してるからには面目にかけても上がろうと、しゃにむにやって上がりましたよ。
途中でやんなっちゃうゲームだと上がれないけど、やってて楽しかったから相当寝不足になりましたよ。
植松：
今回はアマチュアの勝利ですかね。スクウェアのメンツって、単独で独立して音楽で食っていけるか、
絵で食っていけるか、企画で食っていけるかという連中がまだ1人もいないんですよね。
すぎやま：
植松：
いえいえ。平均年齢がまだFFチームでいうと25ぐらいなんですよね。
すぎやま：
ドラクエチームもそうですよ。皆さん若い。僕1人だけ飛び抜けてるんだ。
植松：
結局若い、何かやってやろうという奴らが集まってるんですよね。
そいつらが泥まみれになって一緒くたになって限度知らずの頑張りをするんですよね。
全てのプロの人がそうというわけじゃないんですけど、中にはお金と割り切って仕事をする方もいらっしゃいますよね。
そうするとある程度から先の気力とか頑張りを越すというのは難しいというのがたまにあるじゃないですか。
そういうことが5のチームには無かったんですよ。
とにかく最後の最後まで、〆切のマスターを任天堂に送る朝まで、どこまでできるかということをみんながやったので、
そこらへんの適当なプロの人を集めて作っても、ああいう気合いの入った作品は出来なかったんじゃないかなと思うんですよ。
今になってやってみると、あそこをこうした方がいいというのはうのはいっぱいあるんですけど、
終わった時点ではもうこれ以上はできない、とみんなが思ってるんですよね。僕もあのときはそうでしたしね。
すぎやま：
結局世の中を見てると、FFにしてもドラクエにしてもそうだけど、
好きで好きでとことんまで頑張るという人が集まってるところのゲームがヒットしてるんだよね。
植松：
ゴーストコンポーザー時代の「クライアントからの依頼を再現する能力」は評価されるべき。その要求を達成しうる作曲家としての力量。現代音楽からクラシックまでの幅広いジャンルへの対応力。知名度も良し。
特に吹奏楽界からの圧倒的信頼感はその作品のひとつひとつの完成度の高さを抜きにして実現するものではない。日本では特にOVAジャイアントロボの地球が静止する日が有名か。新劇エヴァにも関わっているがおそらくタイトルほどの知名度はないと思われる。実現すれば長きにわたりタッグを組んできたワルシャワフィルの演奏によるドラクエが聞けるようになるか。
世界に通用する人材としてはこの人を置いて他にない。ドラクエを世界にもっと広めるなら避けては通れないかもしれないが作風が作品に合うかは別問題。
TVアニメから大河ドラマまで、劇伴音楽としての業界外にも通じる知名度は随一。
「あ、服部さんだ」と聞けば分かる極めて個性の強い作曲家でおなじみ。I.Q.や王様のレストランなど。
題名のない音楽会でたまに出演されるマツケンサンバでおなじみの方。劇伴での活躍が目立つが時たまに吹奏楽曲を書いたりするなど活躍の場を選ばない。
ゲーム音楽の現場に深く入り込み製作現場の実際に詳しい点が評価される。最近はゲーム音楽以外の作曲もしている。
実際はスクエニが金を渋ってそこらへんのゲーム音楽しか書けない作曲家だったり、オーケストレーションが不得意な人に任せてクラオタをがっかりさせる（が、囲いの批判なきエコーチェンバー現象で有耶無耶になる）のがオチだろうけど、他にいる？
父親が息子をモーツァルトの再来に仕立て上げるべく7歳3ヶ月だったのを6歳とした話は読んだ。そのせいでベートーヴェンは中年すぎまで自分の年齢を正確に把握できなかったとか。
手塚治虫『ルードウィヒ・B』では、父親はアル中でとんでもない奴だけど根はいい奴で、自由主義者としてベートーヴェンを導く役割を果たしている。まあさすがにこれは現実ではなかったかな。なおこの漫画の中でもベートーヴェンの難聴の驚きの理由が判明している。
青木やよひ『ゲーテとベートーヴェン』には、父親が宮廷に出した手紙の書き出しが「尊敬すべきお慈悲深き大司教兼選帝侯殿下」、結びは「御足下にひれ伏し服従申し上げます」だったと書かれている。ベートーヴェンと父親の関係については、ベートーヴェンが、バッハのカンタータの未完成写譜を「父が書き写したもの」と書き込んで大切にしていた、とある。
謎の女=死
ヴェーゲラーはベートーヴェンの5歳上。ロールヘンは2歳下。ヴェーゲラーとベートーヴェンの出会いのきっかけは明らかではないらしい。ヴェーゲラーの紹介でブロイニング家に出入りするようになった。
手塚治虫『ルードウィヒ・B』ではヴェーゲラーは出てこないが、ロールヘンとの出会いは本作と似ていて、いじめられてたベートーヴェンをロールヘンが助けるシーンになっていた（ただしこれがきっかけでブロイニング家に出入りするようになるわけではない）。
ここで出るか。
強さ、か。生きるための、成し遂げるための。
fffはFuto Final Forever説を信じているけど、第2場で触れた通り交響曲第7番と第8番でベートーヴェンが史上初めてfffを使ったとのこと（第7番は手元にスコアがあるので確認済み）。これは、難聴が関係していたのではないかなと邪推している。難聴の時期は高音があまり使われなくなった（＝自分で聴こえる音で作っていた）らしいし。そしてほぼ聴覚を失ってからは高音が再び使われるようになった、というか、第九は演奏困難な高音であったと。そしてこれも触れた通り、第九にはfffはない（オーケストラの編成の大きさも関係してるのか？）。第九は、実際ちょっと常軌を逸した曲だと思う。聴覚がないからこそ書けた曲。第4楽章のコントラバスとかもそうだけど（これはベートーヴェンのお友達コントラバス奏者のドラゴネッティのせいか）、第3楽章。美しい理想が見えるけど、理想に近い演奏を探してみたけど出会えなかった、何年も前の話だけど。オーケストレーションに難あり、だよなと。もしくは時代がまだベートーヴェンに追いついていないのか。
実際は出入りする間に自然と啓蒙思想に触れていったのかなと想像。
なんか泣ける。朝美マジック？
あらきた。1804年12月。
謎の女「心のおともだち、ナポレオン」
んーー、第4場Bで少し構えていたけど、ここハイリゲンシュタットの遺書だったのかあ。いつの間にかハイリゲンシュタットに移動してた？劇場のままかと思っていた。時間もほんとは結構経ってる設定だったのかなあ（ナポレオンの戴冠式はあったけど、もともとの劇場の時間もふわっとしてるし、伝わるのに時差あるかなと思うし。あ、謎の女からの情報だからリアルタイムだったかな）。気が付ける要素あったかなあ。
難聴や失恋からくる衝動は救済の記憶でおさまった後（実際の遺書ではただ"芸術"が引き留めたと）、心のおともだちナポレオンが皇帝になったショックからのシーンだしなあ。
ベートーヴェン（歌）「
歌い続けろ 聴こえない カラダ
歌い続けろ カラダ カラダの そとに
歌い続けろ 中に鳴り響く音
歌い続けろ 出し尽くすまで
大きく 大きく 大きく もっと
強く 強く 強く きっと
たとえ命 たとえ魂
この体が朽ち果てても
たとえひとり 声もしない
孤独の道 ひた走ろうと」
「大きく」「強く」 3回ずつ（＝fff）。
ハイリゲンシュタットの遺書から該当しそうな箇所を以下に抜いてみる。
私を引き留めたものはただ「芸術」である。自分が使命を自覚している仕事を仕遂げないでこの世を見捨ててはならないように想われたのだ。そのためこのみじめな、実際みじめな生を延引して、この不安定な肉体を――ほんのちょっとした変化によっても私を最善の状態から最悪の状態へ投げ落とすことのあるこの肉体をひきずって生きて来た！――忍従！――今や私が自分の案内者として選ぶべきは忍従であると人はいう。私はそのようにした。――願わくば、耐えようとする私の決意が永く持ちこたえてくれればいい。――厳しい運命の女神らが、ついに私の生命の糸を断ち切ることを喜ぶその瞬間まで。自分の状態がよい方へ向かうにもせよ悪化するにもせよ、私の覚悟はできている。（片山敏彦訳）
遺書の中の「難聴の苦しみ」「孤独の叫び」「自死願望」ついて参考までに抜き追加。長いけど。一部難読字は平仮名に、一部ルビ省略。
社交の楽しみにも応じやすいほど熱情的で活溌な性質をもって生まれた私は、早くも人々からひとり遠ざかって孤独の生活をしなければならなくなった。
しかも人々に向かって――「もっと大きい声で話して下さい。叫んでみて下さい。私はつんぼですから！」ということは私にはどうしてもできなかったのだ。ああ！ 他の人々にとってよりも私にはいっそう完全なものでなければならない一つの感覚（聴覚）、かつては申し分のない完全さで私が所有していた感覚、たしかにかつては、私と同じ専門の人々でもほとんど持たないほどの完全さで私が所有していたその感覚の弱点を人々の前へさらけ出しに行くことがどうして私にできようか！――何としてもそれはできない！――それ故に、私がお前たちの仲間入りをしたいのにしかもわざと孤独に生活するのをお前たちが見ても、私を赦してくれ！ 私はこの不幸の真相を人々から誤解されるようにして置くよりほか仕方がないために、この不幸は私には二重につらいのだ。人々の集まりの中へ交じって元気づいたり、精妙な談話を楽しんだり、話し合って互いに感情を流露させたりすることが私には許されないのだ。ただどうしても余儀ないときにだけ私は人々の中へ出かけてゆく。まるで放逐されている人間のように私は生きなければならない。人々の集まりへ近づくと、自分の病状を気づかれはしまいかという恐ろしい不安が私の心を襲う。
私の脇にいる人が遠くの横笛の音を聴いているのに私にはまったく何も聴こえず、だれかが羊飼いのうたう歌を聴いているのに私には全然聴こえないとき、それは何という屈辱だろう＊＊＊！
たびたびこんな目に遭ったために私はほとんどまったく希望を喪った。みずから自分の生命を絶つまでにはほんの少しのところであった。
そう思っている。
結論から言えば、SIerで数年働いてウォーターフォールを身に刻みつつWeb技術を趣味で学ぶ。その後アジャイルを標榜しているWebスタートアップに転職すれば良い。
往々にして(少なくとも日本における)Webスタートアップのアジャイルは上手く行かない。なぜならアジャイルとはなんたるかをきちんと学ばず、「なんとなく楽そう」とか「今時でイケてそう」みたいな動機で採用するからだ。
あらゆるプロジェクトが炎上しまくった結果、ウォーターフォールに回帰する瞬間が必ずやってくる。しかしWeb系でウォーターフォールの上流工程ができる人材は割と限られていて、その中にSIer出身でコテコテの上流工程やってたエンジニアが入るとかなり重宝されるのである。
アジャイルは、ウォーターフォールの酸いも甘いも経験してその対比でこそ真の利点が見えてくる。そうしてウォーターフォールもアジャイルも分かってる人材になれば、それだけでそのスタートアップでは唯一無二の存在である。
オーケストレーションだとか自然言語処理だとか純粋関数型だとかCSだとかで技術的に尖ろうとしても、そういう高度なものを求めているスタートアップは実際多くはない、というか既に席が埋まっている場合が多い。
T型人材とよく言われるけど、難しいことは何もなくて、タイトルに掲げた人並のものを2つ持っていればいい。OOPも知らない奴らがネストの深さは何層までだとかタブスペースは2つだとかforeach文使ってるやつはクソだとか表面ばかりに囚われて本質見誤って伸びきったスパゲティを量産しているような現場に、レガシーから飛び出したお前らが新風を巻き起こして欲しい。
そんな私の年収は400万です。
１０年２０年以上も前からベースレスのバンドはどんどん実験されていた
元々キックと低域の奪い合いになるから、いてもらわなくてもいいのである
なのでくるりあたりはメンバーにベースがいるので（実質ギターとベースの二人組）、一時期は逆にドラムレス（代わりにオーケストレーション）の方向に実験していたのが面白い
岸田は増田とは違って、「果たして本当にバスドラっているんやろか」とインタビューでぼやいていた
ロックが隆盛になる前、つまりジャズがポップスである頃はベースは今自分のいる位置を教えてくれる重要な楽器であった
しかし決まった曲を毎回同じように演奏するのが当たり前になった単なる様式美の時代、ベースというのは少なくともその存在価値の半分くらいは、もはや惰性や慣習でいるだけと言えるだろう
といっても「響け！ユーフォニアム」で再確認したという話ではない。
いや、確かに上述のアニメでユーフォに興味を持ったのだが、本当にこの楽器の魅力を知ったのはオケでの起用だったりする。
「この楽器の最高の音はこれ！」
という、ある種の予定調和ありきの起用という点にある。
なので、オケでの使われ方だけを見て、その楽器の全てを知った気になるのは早計である。
しかし、オケでの使われ方を把握することで、「楽器の一番美味しい所」を再認識するにはもってこいなのである。
さて、今回聴いたのはユーフォ登場曲ではド定番と言われる、ホルスト作曲の組曲「惑星」から「火星」である。
組曲中、最も有名な「木星」に次ぐ知名度を持つ、「心太が食べたい」のリズムがキャッチーな曲だ。
例の有名なソロは、確かにユーフォの持つ暖かでまろやかな音色を良く活かしている。
これこそ、他の楽器では代わりがいない音だ。
そして曲が進むとトランペットと掛け合いを演じるのだが、向こうがフォルテシモのペット2本で来るのに対し、こちらはフォルテかつユーフォ1本で受ける。
これは鋭いけど細身の音のペットに対し、柔らかく太い音のユーフォでバランスを取った結果だろう。
これまたユーフォの音の特徴を良く勘案したオーケストレーションだと思う。
(動画→https://www.youtube.com/watch?v=L0bcRCCg01I 奏者の自撮りによるダイジェスト→https://www.youtube.com/watch?v=RERBcMwHi34)
「今後更にこの楽器の魅力をオケで光らせるのは、正直相当厳しいかも」
と。
なぜなら、ユーフォの担当する中低音域は、絵に描いたようなレッドオーシャンだからである。
さっきオケの楽器の使われ方は予定調和と書いたが、言い換えるならオケの歴史というのは、作曲者が新しいサウンドを求めて新たな楽器を試し、執拗に篩いにかけてきた歴史でもある。
即ち現在頻繁にオケで見かける楽器は、そうした淘汰をくぐり抜けてきた、いわば選りすぐりなのだ。
そしてユーフォの音域を既に担っている楽器には、金管だけでもホルン、トロンボーンという強力なライバルがいる。
ホルンはオケ草創期からのレギュラーメンバーだし、トロンボーンはレギュラーこそ逃したものの、ベートーヴェンの時代から頻繁に起用されてきた、いわば準レギュラーである。
更に金管以外でもチェロ、ファゴット、バスクラリネットといった楽器が控えている。どれもこれも、数多の名曲で不動の実績を築いてきたメンツだ。
そんな彼らに割って入ってポジションを獲得できる個性がユーフォにあるか…という話である。
同様の話は、サックスにも当てはまる(こちらはオーボエ、コーラングレ、クラリネット、ホルン、トロンボーン、ヴィオラ、チェロ等とカブる)。
一方、ユーフォやサックスと同年代に発明されたチューバは、登場するやいなやオケに起用され始め、今では準レギュラーの地位を勝ち取っている。
「登場した年代が新しい楽器」どうしでハッキリ明暗が分かれた形だが、これはチューバが担う、オケの最低音域にはコントラバスとコントラファゴットしか存在せず、ブルーオーシャン戦略で行けたということだ。
やはりユーフォの活躍する舞台は軍楽隊と英国式金管バンド辺りという結論になるのだろうか。
自分がユーフォという楽器を初めて耳にしたのはEテレの小学生向け音楽番組で、でもオケにいないし「なぜそんな楽器が？」と思ったものだが、あれも金管バンド～吹奏楽の流れがあるからだろう。
作曲者の創意工夫に期待したい。
アレンジとしてのオーケストレーション嫌いだからこの頃流行しているレトロゲームのオーケストラ版とかホントつまんないし全部チェンバロメインでアレンジしたような古楽スタイルのアレンジとかやってほしい、ていうか世代的にはFFのアイリッシュアレンジCDでキャッキャ言ってたのでオーケストレーションやDAWでのミックスより他にやることあるだろ30代SFC直撃世代舐めてんじゃねえぞ食い詰め交響楽団存続のための苦肉の策としてのゲーム音楽なんてしょせんハイプでしょって鼻で笑ってしまう程度には中二病だから、いっそファミコン実機100台用意してそれをリアルタイム演奏で電子楽器オーケストラみたいなことやってほしいです。
流行を勉強しないやつとは仕事したくない
最低限下記は知っててほしい
プロマネならアジャイルサムライとかチケット駆動開発とかリーン・スタートアップとか読んどけ。頼むから。
頼むからこれぐらいは知っといてくれ。確かに流行り廃りがあって、追っていたものが崩壊したときツラいのはわかる。
しかし、上記はもはや流行りでも枯れてきてデファクトスタンダードになっているものばかりだ。
設定ファイルはバージョン管理しちゃうとまずいだろとか、本番とは違うからローカルは自分で手作業で変えろとか、何言ってんだおまえは。オーケストレーションツール使え。
クライアントが困ってるのに、オマエの環境で再現しねーとかあたりまえだろ。自分で環境かえてんだから。同じにしろ。
リリース対応に20時間かかるとか何馬鹿なこと言ってんだ。10人体制で20時間とか1リリースで予算300万超えかよ。本気かよ。
細かくリリースしろ。まとめんな。だから不具合もでかくなる。文言修正だけで3ヶ月待たせるな。機能の追加と軽微な修正は別だ。
あとエクセルやめろ。最初はいいけどメンテがつらすぎる。バグ管理やテストや設計図なんかはもはやそれ用のオンラインツールあるやろ。それ使え。
もう少し最新のヤツは勝手に追え。
俺はそれらがデファクトスタンダードになるかコケるかは責任もてん。
多くの目に触れるようになる前から価格が高騰し、入手困難なCDであるため、これを引用公開することで、多くの人の目に触れることは、昨今の事情に照らし、有用だろうと思い、ここに記しておきます。じゃあ増田で書くなよ、というツッコミは効きません。たぶん期間限定。
佐村河内のスコアを詳細に眺め評価することは、近頃の劇音楽に屡々見られる基本的な技術不足や、必要以上に技を凝らそうとする過剰なテクニックの持て余し。
これらとは明かに一線を画しているという事だ。
第一楽章、邦楽の静謐な、それでいて熱いエネルギーを内に秘めた佇まいから戦いを表現する大オーケストラへの見事な転換、目の眩むような、あたかも生物の細胞分裂の様な声部の増殖の緊張は、来たるべく英雄の出現(心に強く刻み込まれる主題[テーマ])を準備しているのだ。
第二楽章では、一楽章の主要な動機[モティーフ]や主題[テーマ]を巧みに変奏発展させてゆく、限られた時間の中で超絶的展開能力。
全く隙の無い構築力と完璧なオーケストレーションには唯々感嘆するばかりだ。
これらの事が自然に在る、ということ、技術はその為にこそ使われなくてはならない事をこの奇麗なスコアは私達に示してくれている。
私がコーダ部の総譜を受け取りに氏宅に伺った日のこと。
着いてすぐ筆談で、まだ出来てないので待てとのこと。
以降氏は黙したまま延々4時間が流れた。
と突然立ち上がり、未だ見た事も無い80段はあろう巨大な五線紙を取り出し席に着くや否や、嵐の如くペンを走らせ始めた。
それは神憑り的な速さといった感じだった。
何やらスケッチでも書き写しているようだった。
10分も経った頃、｢写譜なら手伝おう｣と立ち上がり氏に近づいた私は思わず目を疑った。
氏が書き写している筈の五線紙の向こうには何も無かったのだ････。
その恐ろしい光影に立ち尽くすばかりだった。
写し取っていたのは頭の中のスケッチだった、以降ペンは一度と止む事無く僅か20分で全ては終わった。
氏は見直しもせず｢ポイ｣と私に手渡した。
後に私が見直したところ、何の落度も無かった事は言う迄も無い。
注：引用者により、ルビを該当する熟語のあとに［］で読みを挿入してある。また、句点ごとに改行し、アラビア数字は半角に変更した。
遠い古からの声―長い間日本の風土の中で培われてきた都節と呼ばれる伝統的な様式―からこの曲は始まる。
この尺八の｢息｣が、はじめは琵琶の力強い一打や笙の開放的な響きを導き、外に開かれていく空間を形づくるが、つづく締太鼓の合いの手を橋渡しとして、今度は逆に人間の持つ陰の部分、尺八の内に籠った響き、そこに影を落とす琴の不穏な調弦や笛の虚ろな息づかいなどが、前との微妙なコントラストとして対置される―ここで提示された様々な要素(おもにコントラストという概念)がこの作品の全体を紡いでいく上での重要なポイントとなっている―。
やがて一本の竹のひびきは12本もの竹(尺八)を呼び(ff)、静かに、しかし豊かにひびき渡る和太鼓の一打が大オーケストラを迎え入れ一転としてスペクタクルな場面に突入する。
前の部分と全く別な世界の様にみえるこの部分は実は冒頭の尺八の旋律と深い関わりを持っている。
譜面を見てみよう。
(譜例1)ここでフレーズの後半にあたるＡという部分にオーケストラが対応する。
(Ａ')。
そして英雄の出現を伝えるファンファーレ(これは西洋で培われてきた伝統だ)につづいて(やはりこれも西洋の伝統的な)ハーモニーのゼクエンツ(鎖)に乗って英雄のテーマが提示され(譜例2)クライマックスを迎えた後、譜例1のＢの和音の固定(オスティナート)による経過句に入る。
ここで邦楽の冒頭部分が新しい状況の上で再び現われる。
尺八がサキソフォーンに、笙がヴァイオリン群に、また12本の尺八は今度は虚ろで怪しげなハーモニーを醸し出し、三味線は乱れ(冒頭の拡大)、琴はますます不穏なアルペジュを掻き鳴らす、一瞬の閃光、地底から沸き起こったかのような轟音から出現したものは英雄のテーマのヴァリエーション、そして輝かしいマーチ(ファンファーレの変奏)―ここで西洋にハーモニーのコントラスト(長三和音と短三和音)を挙げておく。(譜例3)
そして再びスペクタキュラーなシーンが登場し、コーダ(ゼクエンツ部分の変奏、このモティースがその後の楽章で大変重要な役割を果たす)(譜例4)。
二楽章は前半の静かな部分「夜の音楽」(佐村河内談)と後半の激しいアレグロからなるが、前章であらわれた様々なモティーフによる更なるヴァリエーションである。
(一楽章をソナタ形式に於ける提示部と捉えるならば二楽章は展開部、三楽章は再現部とみなすこともできる)
三楽章は前の余韻を受けて｢能楽｣の囃子、コラージュ的部分を経て尺八の冒頭が再現される、ここでは笙のか代わりに弦楽器が増四度上で現れる、実に美事である。
メインテーマがアダージュで(本来の姿で)再現され圧倒的なコーダで締めくくる……
以下は若干の譜例による指摘にとどめるが、この作品は様々な要素を複雑縦横に織り込んだ大変興味深い大曲であり、聴き手は注意深く聴き込む毎に新たな発見を見いださせる至宝の逸品と言える。
引用者注：譜例3には『マーラーの交響曲第8番(第6番かも、とにかく字が小さくて読みにくい)が想起される！』と書いてあるので、もともとマーラーが好きなんだろうと思う。また、誤字と思しきものも原文ママにしてある。
www.youtube.com/watch?v=ukFtX9iZPjU
余談だが、このサウンドトラックは贅沢にもxrcd2を採用している。ネットにある音源とは比べられないぐらい素晴らしい音楽が堪能できる。
アマオケで弦をやって10年以上経つけど、未だに管の人達の曲の嗜好がよく分からなかったりする。
とにかく管の人達って、ロマン派後期から近現代の音楽をやりたがる感じなのだ。
近現代くらいからしか定席のないトロンボーンやチューバがこの傾向なのはまだ分かる。
ティンパニ以外の打楽器も、やはり近現代から積極活用され始めたので、これまたそっちをやりたいだろうと思う。
しかし木管やトランペット・ホルンまで含めて、総じて上に書いたような、言い換えれば「割と大編成志向」なのはどういうことだろう。
スコア眺めてる限り、モーツァルトやベートーヴェンやブラームスの管楽器パートだって十二分に面白そうなのになあ。
木管ホルンの深みのある印象的なアンサンブル、トランペットとティンパニのカッコいいアクセント、どれも弦じゃ絶対経験できないし。
ちなみに弦の意見として言わせてもらうと「オケは弦の豊かな響きが基盤」という意識が非常に強いです。
またヴァイオリンやチェロのメソッドは古典的な造りの曲や、バロックを基本としていたり。
なのでそれに沿ったオーケストレーションをする古典派～ロマン派前期くらいが、どうしても好みになるわけで。
一方、楽器の限界に挑戦するような、弾いててやたらくたびれる書き方をしているロマン派後期以降はちょっと・・・という感じ。
管打楽器の数も多いので、それに負けないよう人をかき集めようにも、曲によっては技術的に難しすぎて、ゲネ本しか来ないようなエキストラにはまず期待できないなんて事情も。
