「オーケストレーション」を含む日記 RSS

はてなキーワード: オーケストレーションとは

2024-01-07

anond:20240107191627

コンテナって呼ばれてるものがどういう概念のものなのか理解してない事はよくわかったからこの際勉強した方がいいよ

その次元理解度だと開発に居られても困るし、オーケストレーションがわからないって自白されると例えばAWS配下にたくさんあるサービスを使いこなすどころか理解できてませんって宣言に等しいので。

anond:20240107191627

k8sDockerコンテナオーケストレーションツールで、結局各コンテナの中ではentrypointが実行されるでしょ?k8sが何か、Dockerとどのような関係にあるかはちゃん理解しておきなよ

2023-07-31

anond:20230731104947

最近最前線から離れててあんまり追えてないけど、現役のとき2008年くらいか10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。

分野にもよるし、調査して試作した結果自分業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。

あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応テスト手法進化もけっこうカロリー高いけどここには書いてない。

自分フロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからいか普通リスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要

ソーシャルコーディング(GitHub)

スマホアプリ(iOS, Android)

NoSQL(memcached, Redis, Cassandra)

暗号通貨

クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)

CI/CD(Travis CI, CircleCI, Jenkins)

トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)

システム(Rust, TypeScript, Haskell)

テスト自動化(xUnitSelenium)

クリーンアーキテクチャ

コンテナDocker

オーケストレーション(Ansible, Kubernetes, Terraform)

機械学習(Python, MATLAB, 線形代数数学知識)

HTML5(WebGL, WebAudio他)

SPA(React, AngularJS, Ember.js, Vue.js)

マイクロサービスアーキテクチャ

3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及

GraphQL

機械学習ライブラリ(Tensorflow, PyTorch, Chainer)

Jupyter Notebook

NFT

モバイルアプリフレームワーク(React Native, Flutter/Dart)

シングルサインオン

多要素認証生体認証

メタバース

2023-05-27

はてな退職エントリを書いています

私は約3年間、はてなエンジニアとして働いていました。

この期間に、様々なプロジェクトに関わり、多くのことを学びました。

今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います

 

## RailsでのWebアプリケーション開発

はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。

はてなログはてなブックマークなどの有名なサービスはもちろん、社内向けのツール新規事業プロトタイプRailsで作っていました。

Railsは、高速に開発できるというメリットがありますが、それと同時にコード品質パフォーマンスにも気を配る必要があります

私は、テストリファクタリングコードレビューなどの技術的なプラクティス積極的に取り入れることで、Railsの開発をより効率的安全に行う方法を学びました。

例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。

また、Pull RequestやPair Programmingといった方法を使ってコードレビューを行い、バグ改善点を見つけたり、知識ノウハウを共有したりしました。

 

## クラウドサービスでのインフラ構築

また、はてなでは、AWSGCPなどのクラウドサービス活用してインフラを構築していました。

私は、DockerKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーションインフラストラクチャ・アズ・コードなどの技術実践しました。

これらの技術は、開発環境と本番環境差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。

私は、モニタリングロギングアラートなどの技術的な仕組みを整備することで、インフラ運用をより安定的信頼性の高いものにする方法を学びました。

例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステム状態パフォーマンス監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。

また、ElasticsearchやFluentdといったツールを使ってログ収集分析を行い、原因究明や改善策の検討に役立てました。

 

## チームでの協働

はてなエンジニアとして働くことで、私は多くの技術的なスキル知識を身につけることができました。

しかし、それ以上に大切だったのは、チームで協力して問題解決することでした。

はてなでは、エンジニアだけでなくデザイナープロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。

私は、コミュニケーションフィードバックドキュメンテーションなどの技術的ではないスキル重要だと感じました。

私は、自分意見提案積極的に発信することで、プロダクトやサービス品質価値を高める方法を学びました。

例えば、私が参加したプロジェクトでは、SlackZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。

また、FigmaMiroといったツールを使ってデザインアイデアの共有やフィードバックを行いました。

 

## 退職への決断

私は、はてなエンジニアとして働くことがとても楽しく充実していました。

しかし、私は自分キャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。

私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。

そこで、私はこの度、はてな退職することにしました。

私は今後、別の会社エンジニアとして働く予定です。

 

## おわりに

はてなで働いた3年間は私にとってかけがえのない財産です。

私は、はてな出会ったすべての人に感謝しています

に私が所属したチームのメンバーには大変お世話になりました。

彼らから学んだことや刺激されたことは数え切れません。

彼らと一緒に仕事ができたことを誇りに思います

彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います

 

以上、AIによるフェイ記事です。

どの程度、真実味がありましたか

2023-04-17

anond:20230415000359

ITエンジニアでもソフトウェアエンジニア(というかこの人の場合旧来の「プログラマ」って感じだ)ではなく、インフラ系ならハッタリ効くしゴリゴリの最新技術は求められないよ。

というか、最新技術がだいたい既存技術仮想化してオーケストレーションできるようにしました程度なので、キャッチアップがめちゃくちゃ楽だから現時点のスキルはあまり問わない。

7-800程度でいいなら「単に経験が長い」というだけで行けるよ。職務経歴書ちゃんと書けるなら。少なくとも俺の経験上場企業数社はそれで入れた実績がある。

しろ小さいとこの方が細かいスキルチェックをしようとしてくる印象があるな。多分人事予算に余裕がないから最大効率を求めるんだろう。

2022-05-17

平成6年まれ私の平成邦楽TOP30

自分語りしかない

30-21

プラスチックガール / CAPSULE (2002)
雪のライスシャワー / dorlis (2005)
雨は毛布のように / キリンジ (2001)
渋谷で5時 / 鈴木雅之菊池桃子 (1993)
接吻 kiss / ORIGINAL LOVE (1993)
ENDLESS SUMMER NUDE / 真心ブラザーズ (1997)
プラチナ / 坂本真綾 (1999)
Giftあなたマドンナ〜 / 土岐麻子 (2011)
Let Me Be With You / ROUND TABLE feat. Nino (2002)
traveling / 宇多田ヒカル (2002)

20-11

LOVE RAIN〜恋の雨〜 / 久保田利伸 (2010)
Slave of Love / ビッケブランカ (2016)
Sinfonia! Sinfonia!!! / 竹達彩奈 (2013)
夢の外へ / 星野源 (2012)
Time to know ~ Be waltz / シートベルツ (2001)
ロマンスの神様 / 広瀬香美 (1993)
LOVE TOGETHER / ノーナ・リーヴス (2000)
LA BOUM ~だってMY BOOM IS ME~ / カジヒデキ (1997)
RAISE YOUR HAND TOGETHER / Cornelius (1994)
ぼくらが旅に出る理由 / 小沢健二 (1994)


10-1

目抜き通り / 椎名林檎トータス松本 (2017)

椎名林檎ちゃんと追ってるわけではなかったけど、「女の子は誰でも」をCMで聞いた時にオッと思い、数年後これを聞いてなるほど~~って頭ブンブン振っちゃったね

https://music.apple.com/jp/album/1385322133?i=1385322148

硝子の少年 / KinKi Kids (1997)

未就学児の当時よく歌っていたらしい(!?) 後になって作者が大物であることを知り驚く

(各自CDで聞いてください)

砂の惑星 / ハチ feat. 初音ミク (2017)

自分ハチ米津玄師楽曲に対して、なんでこんなのが流行ってんだよみたいなマジで穿った見方をしてた、これを聞くまでは……

皮肉まみれの歌詞が当時だいぶ物議をかもしてた気がするけど、曲はそんなのどうでもいいくらい、悔しいくらいカッコいい

https://music.apple.com/jp/album/1268503456?i=1268503458

ファインダー(DSLR remix-re:edit) - MIKUNOPOLIS LIVE - / livetune feat. 初音ミク、The 39s(2011)

ライブ音源です 21世紀未来アイドルがこういう曲で踊ってる(しかロサンゼルスで)という面白

安部潤シンセT-SQUAREリスペクトらしい 生で聞けたらどんなに楽しかっただろう

https://music.apple.com/jp/album/642832495?i=642832943

軒下のモンスター / 槇原敬之 (2011)

まずメロディでこれはHungry Spider以来久しぶりのダークなマッキーじゃ~んと思って、次に歌詞ちゃんと読んで完全に泣いた 同じ性別の人を好きになった人の気持ちがこんなにもわかるか?

この30曲中、歌詞選考に影響した唯一の曲

https://music.apple.com/jp/album/548245136?i=548245147

murmur twins / yu_tokiwa.djw (2002)

ポップンやってた中高の頃、ゲーム内で気になる曲の作曲者を調べたらことごとくwacだったのがちょっと怖かった

その例外がHomesick Pt. 2&3 / orangenoise shortcut、と思ってたけど今調べたら編曲wacが関わってるらしい マジかよ……

なおベース沖井礼二

https://music.apple.com/jp/album/498158513?i=498158523

2012年になって出たロング版(※Spotifyには無い)

最終列車は25時 / Lamp (2004)

配信サービスで後追いで知る(このリスト硝子の少年プラチナを除く2005以前の曲は全部後追いですが)

音楽サブスクにおけるレコメンドエンジンというのは恐ろしい大発明ですね このあたりの(自分能動的に音楽聴く前の)年代のお洒落邦楽って絶対たくさんあるはずなのでこれからも掘っていきたい

https://music.apple.com/jp/album/1486281113?i=1486281117

渚にて / あつぞうくん feat. 初音ミク (2010)

あつぞうくん名義(もともと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 project feat. 初音ミク (2007)

まれて初めて自分の小遣いでCDを買った

今考えると初音ミクの登場から数か月という段階(メルト以前!)でこんなに完成されたスキャットが出てきたことが本当に恐ろしい…… オーパーツですか?

OSTERのオリジナルアルバムに何度もリアレンジリミックスが収録されたり(ほとんどがアルバム最後もしくはそれに準ずるような場所に入ってる 曲順が解釈一致ですありがとうございます)、令和の時代になってもゲームカバーされたり、公式/公認だけでも数えきれないバリエーション存在する

歌い継がれてほしい

https://music.apple.com/jp/album/662012326?i=662012451

配信で聞けるのはベスト盤向けセルフリミックス(↑)(※Spotifyには無い)、プロセカ(ワンダショ)のカバー(Spotifyで聞くならこれ)、PSBハヤシベトモノリによるリミックスのみ

大都会交響楽 / ピチカート・ファイヴ (1997)

渋谷系ニワカのときにたくさん買ったCDの中にあった ベストアルバムPIZZICATO FIVE JPN」の最後の曲だった

攻撃的なリズム隊! 荒ぶるストリングス! キラキラしたブラスセクション! 淡々と歌う2人! 最高~

Don't Take Your Time元ネタ楽曲は全部好きだけどこれは別格

ここまで楽しくて悲しい曲は聞いたことがない

https://music.apple.com/jp/album/1484037087?i=1484037108

1作曲者につき1曲縛りとした

2022-01-30

ヴィジュアル系バンドとしての演奏力がすごいのはLUNASEA

Gravityって曲があるんだけど、主旋律は正直退屈なんだけど、楽曲として聴くオーケストレーションが美しくて完成度が高い。ノスタルジックさえ感じる。

GLAYラルクファンには申し訳ないけど、あの時代ヴィジュアル系ではルナシーが頭一つ飛びぬけてるよね。

XジャパンBOOWYはまた別の意味ですごいし彼らの原典だと思うけど。

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-11-27

anond:20211126224044

コンテナはいものk8s はよくないものであるとして、じゃあ何でコンテナオーケストレーション実現するの? ECS? Fargate? Cloud Run?

と言い出すと単なる場面に応じた取捨選択の話であって、k8sけが絶対ダメってのは極端すぎる意見だな。

2021-10-11

これのソースって雑誌

5chに連投コピペで貼られてたんだけど、ググっても元の文章が出てこない。

すぎやまこういち×植松伸夫


すぎやまこういち1931年東京都生。作曲家日本バックギャモン協会会長

植松伸夫1959年高知県生。神奈川大学外国語学部英語科を卒業後、TVCM等フリー活躍し、1986年スクウェア入社


(要約)


すきやま:

だんだんドラクエ関連のスケジュールだけで1年終わっちゃうみたいな有様になってきちゃって、

あんまり他のことができなくなってきてるんだよね。困ったもんだよ。

ドラクエやると、やれCDブックだアニメときて、レコードブラスバージョンエレクトーンバージョンピアノバージョンが出て、

そうなると色んな出版社ピアノ譜やエレクトーン譜を出す。そんなことやってるから1年潰れちゃうもんね。


植松

そんな忙しい中で「半熟英雄」やって頂きましたからね(笑)


すきやま:

どうしても大変だと思いながら、「このゲームが好きだなあ」ってことになるとついね


植松

まさか本当にやって頂けるとはね。言ってみるもんだなとつくづく思いましたよ(笑)


すきやま:

でも楽しかったね、あれは。FFVも大変だったね。やっと僕も上がったんですけどね。

植松君は働き者だなとつくづく思いましたよ。何曲あるの、あれ?


植松

60近くはあるかもしれないですね。


すぎやま:

60曲あのゲームの中にあるということは、実際作った曲はその裏にもっとあるでしょう。何曲ぐらい?


植松

1コーラス作ったという感じで言ったら100曲ぐらいいってるかもしれないですね。


すぎやま:

働き者だなあ(笑)


植松

数撃って当てようという方向でいってますから(笑)

曲数が多いというのも一既にいいとは言えないとも思ってるんですよね。

1曲1曲のイメージが薄らいじゃいますからね。


すぎやま:

それはあるよ。IVときのがVより曲数少なかったでしょう?


植松

そんなでもないんですけどね、それでも10曲ぐらいは少ないかな?


すぎやま:

そうでしょ。やってる時はこの曲面白いなと思うんだけど、終わったあと覚えてる数が少ない感じがしたね。

その原因は何だろうと思ったんだけど、多すぎるというのがあるのかもしれないな。

でもやっぱりどんどん意欲が湧いて、ここはこういう曲にしちゃおう、ここはこうしようっていうのが出てきちゃうものだよね。


植松

作ってる方としてはまだ足りないんじゃないかという気もするんですよね。完成したあとに自分でやってみますよね。

そうすると、こことここの音楽変わってないやっていうところがいくつかあるんですよ。

から作った本人は全部曲覚えてるから別に問題ないんですけど、

自分以外の一般の人にとっては多いかなとは思ってるんですけどね。

30曲に抑えようとしたんですよ。IVときちょっと多いと思ったんです。

今回は絞り込んでやろうと思ってたんですけど、欲が出てしまますね。


すぎやま:

僕も曲を絞り込むとき断腸の思いでね。切る作業が大変ですよ。

前にも言ったと思うんだけど、むこうのミュージカルなんかを見ると本当に曲数少ないんだよね。

でも植松さんのやり方でいいなと思うのは、1つの曲をシーンに応じてアレンジを変えて出すケースが多いでしょう。

それでカバーしていくともっと絞り込めるかもしれない。


植松

なんであんなに増えちゃったんだろう(笑)


すきやま:

働き者なんだよ。FFVの曲は植松さんの趣味趣向がはっきり出てるから

それがある意味でいい個性になってていいなというのがありますね。

スコットランド民謡をはじめとして、民族音楽への傾斜というのがあるでしょ。


植松

今回そのアイルランドリールっぽい曲を入れたのって初めてなんですけど、あれを入れます

ユーザー意見なんかのハガキに「アイルランド行ってきて帰ってきたらもうこれだ」というのがあるんですよ(笑)

別にアイルランドから帰ってきて、その影響受けてやってるわけじゃないんですけど。

以前から凄く民族音楽に興味がありまして、入れたかったんですけどファミコンときとかって難しいじゃないですか。


すぎやま:

ちょっとやりにくいよね。


植松

いつかやってやろうと思ってたんですけど、あんまり興味本位民族音楽好きだから

入れるというのも安っぽく見えてイヤかなと思ったんですけどね。

先日、すぎやま先生がうちの職場にいらした時にお話ししたんですけど、今トルコ音楽を習いに行ってまして、

そういう教室へ行くと民族楽器かいっぱい売ってるんですよ。


すぎやま:

なんか君の部屋に不思議楽器が置いてありましたよね。


植松

日本人だったら日本音楽ルーツとして民謡とかがあるはずだと思ってるんですよ。

日本に昔からある音楽自分の血の中にあるはずだって自分では思ってるんですけど、

一度「雅楽(古来の宮廷音楽総称)」の“ひちりき”(雅楽用の竹製管楽器)を習いに行ったことがあるんです。

そうすると自分の中に流れている血というよりも、逆にそれがすごく新しい、

ブライアン・イーノシンセサイザー音楽に近い印象があったんですよね。


すぎやま:

笙(雅楽用の管楽器)のハーモニーなんかは音の響きが非常にシンセサイザー的な新しさがあるよね。


植松

そうなんですよ。だからこれはものすごく面白いけど、自分にとっての血ではない気がしたんですよ。

雅楽朝鮮からのものですけどね、そういうルーツみたいなものを考えていったら、

逆にヨーロッパ民族音楽がすごく自分にピンとくるものがあったんです。

だったらそんな日本人のルーツかいってないで

自分にとってピンとくるものを追っかけていく方が面白いんじゃないだろうかと思って、

最近自分日本人だから日本古来の音楽をどうのこうのという考えはなくなってきてるんですよね。


すぎやま:

僕ら日本人で日本の文化の中で暮らしていると、いつかは三味線音楽や琴の音楽が耳に触れてるわけ。

和風喫茶レストランエアラインなんかでもいつの間にか聞こえてくる。

アメリカで生まれ住んでるとそれは耳に触れないで大人なっちゃうでしょう。

僕らは耳に触れてるから、知らない間にそういう音感は身についてると思うの。


僕が植松さんの音楽でこの人やっぱり日本人だと感じたのは、

町の音楽「ミーファー」ってメロディがいくときに、もう1つの声部が「ミーミー」とそのまま引っ張って、

ミとファが平気でガチャーンと使ってるのがあるでしょう(トゥールの村などの音楽)。

あれって西洋音楽で育った人では絶対やらないことなんですよ。


植松

バッテンなんですよね。


すぎやま:

植松さんはあれにある種の美しさを感じるからやってるわけでしょう。

で、僕も日本人だから聞いて「あ、ここいいな」と思ったんですよ。

「ソーミーファー」というのと「ソーミーミー」というところでミとファがぶつかっているのは、

西洋音楽エフメジャーセブンの中のミとファのぶつかりの意味とは全然違う意味のミとファでしょ。

それは江戸時代三味線や琴の音楽しょっちゅうやってることなんだよな。

ラファミミファミミファファミ」といってるときに、1は「ミミミ」といってミとファがぶつかってるという、

そういうテンションに美しさを感じるという江戸時代音楽家らの伝統みたいな感覚の流れがあるんだよね。

あの部分を聞いて植松伸夫もやっぱり日本人だと思ったんですよ。

で、僕もアレをイヤだと思わずに、あぁこれいいなと感じて、僕も日本人だなと再確認したんです。

意識的にやらずに自然にやったんでしょう?


植松

僕はフラットナインのぶつかり具合とか、

ミとファの半音メロディ伴奏が平気でぶつかることがしばしばあるんですよね。

自分でもああぶつかってるな、クラシック音楽テストなら絶対バツだなと思っても、

その響き欲しいしと思ってそのまま残すこともあるんですよ。


すぎやま:

それが間違いか間違いじゃないかというのは、感覚的にそのぶつかりが許せるかどうかなのよ。

いいと思うかどうかなのね。だから西洋音楽なんかも近代音楽以降はガンガンぷつかるでしょう。

それが前後関係音楽全体の姿からいって、感覚的にこれが美しいと思えるものはマルなのね。

ミとファのぶつかりあいが美しいと思える感受性があってやったものであれば間違いじゃないんだよ。

ただそれが自分一人でいいと思ってるだけで、世の中全員が気持ち悪いと思ったら

これは単なるひとりよがりしかないんだよね。


植松

難しいですよね。音楽学問にした人というのは、かなり強引だと思ってるんですよ。

どうやって音楽の点つけるんだろうって未だに僕思ってるんですよね。

中学校を通して音楽というもの学校教育に取り入れて100点取った人は偉い、

50点取った人はしっかりしなさいという教育を受けてるから

大人になって楽器を手にしなくなっちゃう人が多いんじゃないでしょうかね。


すぎやま:

音楽教育というのがどうあるべきかというものは、これはもっと考えなくてはいけない問題で、

文部省現場教師の考え方に反省点は多々あると思いますよ。


植松

すごい話してますよね(笑)文部省がどうだって


すぎやま:

笛を吹いたことについて点数つけることよりも、笛吹く楽しさをわからせるのが大事だよね。

音楽の楽しさを感じてもらうというのはとても大事なことでね。

からファイナルファンタジーとかドラゴンクエスト音楽というのは大事なんですよ。


植松

最近音楽全然興味ない子供達でもゲームとかで遊んでて、

ドラゴンクエスト音楽が好きになってコンサート行きますよね。

すぎやま先生なんかのコンサートはフルオーケストラでやってらっしゃるでしょう。

それはものすごい影響力だと思うんですよね。

子供オーケストラを生で聞くチャンスが普段あるかというと、少なくとも僕は子供の頃そんな経験はしてないんですよ。

そうすると、ある意味ですごく羨ましいんですよね。小学校2-3年という頃に、N響の音が年に1回、生で聞けるわけでしょう。


すぎやま:

他のオケなんかのコンサート数えると、20-30回やってるよ。全部ドラクエじゃないにしても、1コーナーとかね。

から、あちこちに頼まれて棒振りに行く仕事もやってます。それは大事なことだからね。

ドラクエの棒振りは何はなくとも行くようにしてますけど。


植松

教育の一環ですよね(笑)


すぎやま:

しかし、いつもゲーム音楽作るときに、昔の大作曲家作品聞くじゃない。

とてもかなわないなと思うことが多いね


植松

すぎやまさんがそんなこと言ったらこちらの立場はどうなるんですか(笑)


すぎやま:

昨日久しぶりにバレエ見ようと思って神奈川県民ホールに「くるみ割り人形」見に行ったの。

チャイコフスキーのド天才めって感じだよ(笑)。とんでもない天才だね。


植松

チャイコフスキーは僕もすごく好きですね。音楽は誰が好きなんですかなんてインタビューとかであるじゃないですか。

そのときは一番最初チャイコフスキーを挙げますね。


すぎやま:

とんでもない大天才だよね、あの人は。

あの時代20世紀の音楽家が考えて書くようなヴォイシングやってたりするわけよ。オーケストレーションうまいこと。


植松

この前、西田敏行ロシアに行ってチャイコフスキー足跡を辿るという番組テレビでやってたんですよ。

僕もチャイコフスキー好きだから見てたんですけど、チャイコフスキーホモであるというのを聞いて、

「ああ良かった」と思ったんですよね(笑)


すきやま:

その良かったというのはどういう意味なの?


植松

どこかプラマイゼロじゃないとダメということです(笑)

チャイコフスキー人間だったんだなというね。ま、噂なんですけどね。


すきやま:

モーツァルトなんか完全にいってるよね。大天才でも大欠点があるという。


植松

チャイコフスキーしろモーツァルトしろメロディが非常にわかやすいんですよね。

クラシックって難しいから嫌いという人が多いですけど、そんなことないと思うんですよ。


すきやま:

ベートーベンとかブラームスあたりはみんなそうだよ。いいメロディもってるよ。


植松

やっぱりメロディなんじゃないかという気がするんですよ。


すぎやま:

くそうだと思いますよ。


植松

からドラクエなんかはオーケストラでやっても子供が聞けるんですよ。


すぎやま:

ドラクエにしてもFFにしてもメロディ大事にしてるからそこに強みがあるでしょう。

他にもFFでは民族音楽的なのがありましたな。デデンッデデンッ…てやつ(笑)


植松

民族音楽というか黒魔術の呪術音楽のようなやつですね。


すきやま:

からそのうちトルコも出てくるぞ(笑) FFでは吟遊詩人というジョブがあるじゃない。

吟遊詩人マップの中のトルコアイルランドみたいなところへ行ったりするとそこの音楽を覚えて、

それを戦闘中に唄うと何かが起こるみたいなことがあれば面白いんじゃない。


植松

また曲数増えちゃいます(笑)


すぎやま:

増えるね(笑) でも吟遊詩人というジョブがあるから使えそうな気もするね。


植松

一度何かに絡めてやってやろうと思ってるんですけどね。

どうしても容量がそういう余分なところまで回らないんですよ。


すぎやま:

他を減らさなきゃならないからね。町の音楽全部一緒にしたり。


植松

でも町は2個だけですからね。マップの曲も3つだし。


すぎやま:

ダンジョンも違う?そんな気もしたんだけど。


植松

いや、ダンジョンという曲は1曲しか用意してないんですよね。他で使ってるのを使いまわしてるんです。


すぎやま:

でもなんかすごく多い気がしたな。


植松

実際多いんですよね。飛空艇は1曲ですし、チョコボは2曲だし。


すぎやま:

チョコボはまた面白いね。あの音楽と動きを見事にシンクロさせてて良かった。


植松

あそこらへんはプログラマなんかと楽しんで作ってましたよ。


すぎやま:

ピアノお稽古面白かった。


植松

あれも最後は何の曲にしようかということで、うちの坂口が、

ヘタクソなやつが最後コンサートピアニストぐらいにしてくれと言われたんで、

最初メトロノームにも合わせられないようなところから始めて、最後ドビュッシーまで弾けちゃうんですけど、

あのドビュッシーの曲(月の光)をみんなあんまり知らないんで、ガッカリしちゃったんです。


すぎやま:

グリークとかチャイコフスキーピアノコンチェルトみたいな方がコンサートピアニストみたいな気がするからね。

僕に相談してくれれば良かったのに(笑)


植松

そうですよね。最後のが弱かったのが残念だったな。


すぎやま:

でもああいう遊びの部分も楽しかったよね。


植松

息抜きというやつですね。でも結構一生懸命やっちゃうんで、息抜きできなくなっちゃうんですけど。


すぎやま:

作ってる本人はいいんだよ。遊ぶ方は息抜きできるんだから植松さんはドラクエは上がったの?


植松

実は最後ダンジョンの手前でFFVアレンジCD仕事に入っちゃいまして、まだなんですよ。


すぎやま:

上がってないの!?


植松

申し訳ないっす(笑)

今日までに終わらせるつもりだったんですけど。


すぎやま:

僕は対談頼まれときに、12月中だと聞いてそれまでにFFVを終わらせる自信ないって言ってたんだけど、

元祖プロゲーマーを称してるからには面目にかけても上がろうと、しゃにむにやって上がりましたよ。

途中でやんなっちゃゲームだと上がれないけど、やってて楽しかたから相当寝不足になりましたよ。


植松

今回はアマチュア勝利ですかね。スクウェアメンツって、単独独立して音楽で食っていけるか、

絵で食っていけるか、企画で食っていけるかという連中がまだ1人もいないんですよね。


すぎやま:

植松さんは大丈夫じゃない。


植松

いえいえ。平均年齢がまだFFチームでいうと25ぐらいなんですよね。


すぎやま:

ドラクエチームもそうですよ。皆さん若い。僕1人だけ飛び抜けてるんだ。


植松

結局若い、何かやってやろうという奴らが集まってるんですよね。

そいつらが泥まみれになって一緒くたになって限度知らずの頑張りをするんですよね。

全てのプロの人がそうというわけじゃないんですけど、中にはお金と割り切って仕事をする方もいらっしゃいますよね。

そうするとある程度から先の気力とか頑張りを越すというのは難しいというのがたまにあるじゃないですか。

そういうことが5のチームには無かったんですよ。

とにかく最後最後まで、〆切のマスター任天堂に送る朝まで、どこまでできるかということをみんながやったので、

そこらへんの適当プロの人を集めて作っても、ああい気合いの入った作品は出来なかったんじゃないかなと思うんですよ。

今になってやってみると、あそこをこうした方がいいというのはうのはいっぱいあるんですけど、

終わった時点ではもうこれ以上はできない、とみんなが思ってるんですよね。僕もあのときはそうでしたしね。


すぎやま:

結局世の中を見てると、FFにしてもドラクエにしてもそうだけど、

好きで好きでとことんまで頑張るという人が集まってるところのゲームがヒットしてるんだよね。


植松

その気合いみたいなものが通じるんですかね。

Permalink | 記事への反応(0) | 19:44

2021-10-07

次のドラクエ作曲家を考える

新垣隆

ゴーストコンポーザー時代の「クライアントからの依頼を再現する能力」は評価されるべき。その要求を達成しうる作曲家としての力量。現代音楽からクラシックまでの幅広いジャンルへの対応力。知名度も良し。

天野正道

特に吹奏楽からの圧倒的信頼感はその作品ひとつひとつの完成度の高さを抜きにして実現するものではない。日本では特にOVAジャイアントロボ地球が静止する日が有名か。新劇エヴァにも関わっているがおそらくタイトルほどの知名度はないと思われる。実現すれば長きにわたりタッグを組んできたワルシャワフィル演奏によるドラクエが聞けるようになるか。

久石譲

世界通用する人材としてはこの人を置いて他にない。ドラクエ世界もっと広めるなら避けては通れないかもしれないが作風作品に合うかは別問題

菅野よう子

TVアニメから大河ドラマまで、劇伴音楽としての業界外にも通じる知名度は随一。

服部隆之

「あ、服部さんだ」と聞けば分かる極めて個性の強い作曲家でおなじみ。I.Q.や王様のレストランなど。

宮川彬良

題名のない音楽会でたまに出演されるマツケンサンバでおなじみの方。劇伴での活躍が目立つが時たまに吹奏楽曲を書いたりするなど活躍の場を選ばない。

浜渦正志

ゲーム音楽現場に深く入り込み製作現場の実際に詳しい点が評価される。最近ゲーム音楽以外の作曲もしている。


実際はスクエニが金を渋ってそこらへんのゲーム音楽しか書けない作曲家だったり、オーケストレーションが不得意な人に任せてクラオタをがっかりさせる(が、囲いの批判なきエコーチェンバー現象有耶無耶になる)のがオチだろうけど、他にいる?

2021-02-14

fff -フォルティッシッシモ-』〜歓喜に歌え!〜 第5場

anond:20210213232411

第5場実況

A 不幸の記憶
B 不幸の記憶

ベートーヴェン父親「息子は5歳」

少年ベートーヴェン10歳だ」

父親が息子をモーツァルトの再来に仕立て上げるべく7歳3ヶ月だったのを6歳とした話は読んだ。そのせいでベートーヴェン中年すぎまで自分の年齢を正確に把握できなかったとか。

少年ベートーヴェン「そんなへんな歌、音楽になんかできないよ!(怒)」

んー、ボン選帝侯にたてついたエピソードは知らないなあ。

手塚治虫ルードウィヒ・B』では、父親アル中でとんでもない奴だけど根はいい奴で、自由主義者としてベートーヴェンを導く役割果たしている。まあさすがにこれは現実ではなかったかな。なおこの漫画の中でもベートーヴェン難聴の驚きの理由が判明している。

青木やよひ『ゲーテベートーヴェン』には、父親宮廷に出した手紙の書き出しが「尊敬すべきお慈悲深き大司教選帝侯殿下」、結びは「御足下にひれ伏し服従申し上げます」だったと書かれている。ベートーヴェン父親関係については、ベートーヴェンが、バッハカンタータ未完成写譜を「父が書き写したもの」と書き込んで大切にしていた、とある

C 不幸の記憶

運命》の動機

謎の女(少年ベートーヴェンに向かって)「寒いわね、凍りつくように。痛い?」

謎の女=死

D 救済の記憶

ヴェーゲラーはベートーヴェンの5歳上。ロールヘンは2歳下。ヴェーゲラーとベートーヴェン出会いきっかけは明らかではないらしい。ヴェーゲラーの紹介でブロイニング家に出入りするようになった。

手塚治虫ルードウィヒ・B』ではヴェーゲラーは出てこないが、ロールヘンとの出会いは本作と似ていて、いじめられてたベートーヴェンをロールヘンが助けるシーンになっていた(ただしこれがきっかけでブロイニング家に出入りするようになるわけではない)。

ロールヘンには弟はいたけど妹はいなかった模様。

少年ベートーヴェンf3つなんて記号はないんだ」

ここで出るか。

少年ベートーヴェン「(fffを出すには)この中に(心の中に)、強い気持ちを起こさなきゃ」

強さ、か。生きるための、成し遂げるための。

fffはFuto Final Forever説を信じているけど、第2場で触れた通り交響曲第7番と第8番でベートーヴェンが史上初めてfffを使ったとのこと(第7番は手元にスコアがあるので確認済み)。これは、難聴関係していたのではないかなと邪推している。難聴の時期は高音があまり使われなくなった(=自分で聴こえる音で作っていた)らしいし。そしてほぼ聴覚を失ってからは高音が再び使われるようになった、というか、第九は演奏困難な高音であったと。そしてこれも触れた通り、第九にはfffはない(オーケストラの編成の大きさも関係してるのか?)。第九は、実際ちょっと常軌を逸した曲だと思う。聴覚がないからこそ書けた曲。第4楽章コントラバスとかもそうだけど(これはベートーヴェンのお友達コントラバス奏者のドラゴネッティのせいか)、第3楽章。美しい理想が見えるけど、理想に近い演奏を探してみたけど出会えなかった、何年も前の話だけど。オーケストレーションに難あり、だよなと。もしくは時代がまだベートーヴェンに追いついていないのか。

少年ベートーヴェン貴族の施しはいらない!」

ヴェーゲラー「その金は、施しじゃない!僕らの給金だ。君の音楽の代金だよ」

泣ける。自由主義使者フリーメーソン会員ヴェーゲラー。

ブロイニング夫人勉強しなさい(慈愛)」

実際は出入りする間に自然啓蒙思想に触れていったのかなと想像

執事「暗がりを照らす、ちっさな炎は、この中に」

E 革命記憶

ヴェーゲラー「行くんだろ、君も。ウィーンへ」

実際はハイドン評価されて。

なんか泣ける。朝美マジック

F ナポレオン戴冠式

あらきた。1804年12月

謎の女「心のおともだち、ナポレオン

笑。増田史上いちばん合ってる役だわ真彩さん。

G ハイゲンシュタットの遺書

んーー、第4場Bで少し構えていたけど、ここハイゲンシュタットの遺書だったのかあ。いつの間にかハイゲンシュタットに移動してた?劇場のままかと思っていた。時間もほんとは結構経ってる設定だったのかなあ(ナポレオン戴冠式はあったけど、もともとの劇場時間もふわっとしてるし、伝わるのに時差あるかなと思うし。あ、謎の女から情報からリアルタイムだったかな)。気が付ける要素あったかなあ。

難聴失恋からくる衝動は救済の記憶でおさまった後(実際の遺書ではただ"芸術"が引き留めたと)、心のおともだちナポレオン皇帝になったショックからのシーンだしなあ。

ベートーヴェン(歌)「

歌い続けろ 聴こえない カラダ

歌い続けろ カラダ カラダの そとに

歌い続けろ 中に鳴り響く音

歌い続けろ 出し尽くすまで

大きく 大きく 大きく もっと

強く 強く 強く きっと

たとえ命 たとえ魂

この体が朽ち果てても

たとえひとり 声もしない

孤独の道 ひた走ろうと」

「大きく」「強く」 3回ずつ(=fff)。

ハイゲンシュタットの遺書から該当しそうな箇所を以下に抜いてみる。

私を引き留めたものはただ「芸術である自分が使命を自覚している仕事を仕遂げないでこの世を見捨ててはならないように想われたのだ。そのためこのみじめな、実際みじめな生を延引して、この不安定な肉体を――ほんのちょっとした変化によっても私を最善の状態から最悪の状態へ投げ落とすことのあるこの肉体をひきずって生きて来た!――忍従!――今や私が自分の案内者として選ぶべきは忍従であると人はいう。私はそのようにした。――願わくば、耐えようとする私の決意が永く持ちこたえてくれればいい。――厳しい運命女神らが、ついに私の生命の糸を断ち切ることを喜ぶその瞬間まで。自分状態がよい方へ向かうにもせよ悪化するにもせよ、私の覚悟はできている。(片山敏彦訳

遺書の中の「難聴の苦しみ」「孤独叫び」「自死願望」ついて参考までに抜き追加。長いけど。一部難読字は平仮名に、一部ルビ省略。

社交の楽しみにも応じやすいほど熱情的で活溌な性質をもって生まれた私は、早くも人々からひとり遠ざかって孤独生活をしなければならなくなった。

しかも人々に向かって――「もっと大きい声で話して下さい。叫んでみて下さい。私はつんぼですから!」ということは私にはどうしてもできなかったのだ。ああ! 他の人々にとってよりも私にはいっそう完全なものでなければならない一つの感覚聴覚)、かつては申し分のない完全さで私が所有していた感覚、たしかにかつては、私と同じ専門の人々でもほとんど持たないほどの完全さで私が所有していたその感覚の弱点を人々の前へさらけ出しに行くことがどうして私にできようか!――何としてもそれはできない!――それ故に、私がお前たちの仲間入りをしたいのにしかもわざと孤独生活するのをお前たちが見ても、私を赦してくれ! 私はこの不幸の真相を人々から誤解されるようにして置くよりほか仕方がないために、この不幸は私には二重につらいのだ。人々の集まりの中へ交じって元気づいたり、精妙な談話を楽しんだり、話し合って互いに感情を流露させたりすることが私には許されないのだ。ただどうしても余儀ないときにだけ私は人々の中へ出かけてゆく。まるで放逐されている人間のように私は生きなければならない。人々の集まりへ近づくと、自分の病状を気づかれはしまいかという恐ろしい不安が私の心を襲う。

私の脇にいる人が遠くの横笛の音を聴いているのに私にはまったく何も聴こえず、だれかが羊飼いのうたう歌を聴いているのに私には全然聴こえないとき、それは何という屈辱だろう***!

たびたびこんな目に遭ったために私はほとんどまったく希望を喪った。みずから自分生命を絶つまでにはほんの少しのところであった。

おお、人々よ、お前たちがやがてこれを読むときに、思え、いかばかり私に対するお前たちの行ないが不正当であったかを。

第5場まとめ

2021-02-04

人並のIT技術と人並のPM能力を組み合わせれば年収1000万はカタい

そう思っている。

結論から言えば、SIerで数年働いてウォーターフォールを身に刻みつつWeb技術趣味で学ぶ。その後アジャイル標榜しているWebスタートアップ転職すれば良い。

往々にして(少なくとも日本における)Webスタートアップアジャイルは上手く行かない。なぜならアジャイルとはなんたるかをきちんと学ばず、「なんとなく楽そう」とか「今時でイケてそう」みたいな動機採用するからだ。

あらゆるプロジェクト炎上しまくった結果、ウォーターフォール回帰する瞬間が必ずやってくる。しかWeb系でウォーターフォール上流工程ができる人材は割と限られていて、その中にSIer出身コテコテ上流工程やってたエンジニアが入るとかなり重宝されるのである

アジャイルは、ウォーターフォールの酸いも甘いも経験してその対比でこそ真の利点が見えてくる。そうしてウォーターフォールアジャイルも分かってる人材になれば、それだけでそのスタートアップでは唯一無二の存在である

オーケストレーションだとか自然言語処理だとか純粋関数型だとかCSだとかで技術的に尖ろうとしても、そういう高度なものを求めているスタートアップは実際多くはない、というか既に席が埋まっている場合が多い。

T型人材とよく言われるけど、難しいことは何もなくて、タイトルに掲げた人並のものを2つ持っていればいい。OOPも知らない奴らがネストの深さは何層までだとかタブスペースは2つだとかforeach文使ってるやつはクソだとか表面ばかりに囚われて本質見誤って伸びきったスパゲティを量産しているような現場に、レガシーから飛び出したお前らが新風を巻き起こして欲しい。

そんな私の年収は400万です。

2020-02-10

anond:20200210093129

実は増田意見的を得てて、

10年20年以上も前からベースレスバンドはどんどん実験されていた

ジョンスペ、キーンホワイトストライプス、etc...

そして出た結論は「確かに特に必要いね」であった

だって普通に音楽として成立しちゃってるんだもんそいつ

元々キックと低域の奪い合いになるから、いてもらわなくてもいいのである

なのでくるりあたりはメンバーベースがいるので(実質ギターベースの二人組)、一時期は逆にドラムレス(代わりにオーケストレーション)の方向に実験していたのが面白い

岸田は増田とは違って、「果たして本当にバスドラっているんやろか」とインタビューでぼやいていた

ロックが隆盛になる前、つまりジャズポップスである頃はベースは今自分のいる位置を教えてくれる重要楽器であった

コード情報を裏で常に明示してくれないとソロ回しはきつい

しかし決まった曲を毎回同じように演奏するのが当たり前になった単なる様式美時代ベースというのは少なくともその存在価値の半分くらいは、もはや惰性や慣習でいるだけと言えるだろう

2020-01-17

うそう、オーケストラがないっせいにやるねん

・・

ってオーケストレーションや、アプリが連動するねん。オーケストラやない。

2019-11-04

個別どりですらなく

音源買ってきて

DTMで合成した音楽

DTMオーケストレーションと呼ぶといわれて

おれは死にたかった

dockerオーケストレーションって

環境を合わせる努力プログラマー放棄するものオーケストレーションなの?

ふつうそれって演奏者=プログラマー相談して環境を合わせるんじゃねーの?

個別に録音してDTMツールMIXするのがどうしてオーケストレーションなの?

おしえてえらいひと

2018-11-29

高度に発達した科学技術魔法と見分けがつかないとかいうけど

からってすっげー高度なオーケストレーションツールだったりをインストールしたりするコマンドに conjureとか jujuとかつけちゃうの、なんなん… 

しろカーゴ・カルト的な奴じゃん…

オーケストレーションって最近よくつかわれるけれど

オーケストラから来てる言葉だって理解できないと大きいケツしかイメージできないよな。

2017-01-02

ユーフォの魅力の再確認

といっても「響け!ユーフォニアム」で再確認したという話ではない。

いや、確かに上述のアニメユーフォに興味を持ったのだが、本当にこの楽器の魅力を知ったのはオケでの起用だったりする。

オケ楽器の使い方の特徴は

「この楽器の最高の音はこれ!」

という、ある種の予定調和ありきの起用という点にある。

なので、オケでの使われ方だけを見て、その楽器の全てを知った気になるのは早計である

しかし、オケでの使われ方を把握することで、「楽器の一番美味しい所」を再認識するにはもってこいなのである


さて、今回聴いたのはユーフォ登場曲ではド定番と言われる、ホルスト作曲組曲惑星から火星である

組曲中、最も有名な「木星」に次ぐ知名度を持つ、「心太が食べたい」のリズムキャッチーな曲だ。

例の有名なソロは、確かにユーフォの持つ暖かでまろやかな音色を良く活かしている。

これこそ、他の楽器では代わりがいない音だ。

そして曲が進むとトランペットと掛け合いを演じるのだが、向こうがフォルテシモのペット2本で来るのに対し、こちらはフォルテかつユーフォ1本で受ける。

これは鋭いけど細身の音のペットに対し、柔らかく太い音のユーフォバランスを取った結果だろう。

これまたユーフォの音の特徴を良く勘案したオーケストレーションだと思う。

(動画https://www.youtube.com/watch?v=L0bcRCCg01I 奏者の自撮りによるダイジェストhttps://www.youtube.com/watch?v=RERBcMwHi34)


しかし、それと同時に考え込んでしまった。

「今後更にこの楽器の魅力をオケで光らせるのは、正直相当厳しいかも」

と。

なぜなら、ユーフォ担当する中低音域は、絵に描いたようなレッドオーシャンからである


さっきオケ楽器の使われ方は予定調和と書いたが、言い換えるならオケ歴史というのは、作曲者が新しいサウンドを求めて新たな楽器を試し、執拗に篩いにかけてきた歴史でもある。

即ち現在頻繁にオケで見かける楽器は、そうした淘汰をくぐり抜けてきた、いわば選りすぐりなのだ

そしてユーフォの音域を既に担っている楽器には、金管だけでもホルントロンボーンという強力なライバルがいる。

ホルンオケ草創期からレギュラーメンバーだし、トロンボーンレギュラーこそ逃したものの、ベートーヴェン時代から頻繁に起用されてきた、いわば準レギュラーである

更に金管以外でもチェロファゴットバスクラリネットといった楽器が控えている。どれもこれも、数多の名曲で不動の実績を築いてきたメンツだ。

そんな彼らに割って入ってポジションを獲得できる個性ユーフォにあるか…という話である

同様の話は、サックスにも当てはまる(こちらはオーボエコーラングレクラリネットホルントロンボーンヴィオラチェロ等とカブる)。

一方、ユーフォサックスと同年代発明されたチューバは、登場するやいなやオケに起用され始め、今では準レギュラー地位を勝ち取っている。

「登場した年代が新しい楽器」どうしでハッキリ明暗が分かれた形だが、これはチューバが担う、オケの最低音域にはコントラバスコントラファゴットしか存在せず、ブルーオーシャン戦略で行けたということだ。


やはりユーフォ活躍する舞台軍楽隊英国式金管バンド辺りという結論になるのだろうか。

自分ユーフォという楽器を初めて耳にしたのはEテレ小学生向け音楽番組で、でもオケにいないし「なぜそんな楽器が?」と思ったものだが、あれも金管バンド吹奏楽の流れがあるからだろう。

もっとオケでもあの優しい音色を聴きたいものだが。

作曲者の創意工夫に期待したい。

2016-11-23

ゲーム音楽オーケストラアレンジダサい

アレンジとしてのオーケストレーション嫌いだからこの頃流行しているレトロゲームオーケストラ版とかホントつまんないし全部チェンバロメインでアレンジしたような古楽スタイルアレンジとかやってほしい、ていうか世代的にはFFアイリッシュアレンジCDでキャッキャ言ってたのでオーケストレーションDAWでのミックスより他にやることあるだろ30代SFC直撃世代舐めてんじゃねえぞ食い詰め交響楽団存続のための苦肉の策としてのゲーム音楽なんてしょせんハイプでしょって鼻で笑ってしまう程度には中二病から、いっそファミコン実機100台用意してそれをリアルタイム演奏電子楽器オーケストラみたいなことやってほしいです。

2015-07-09

IT業界での悪は流行を追わないこと

流行勉強しないやつとは仕事したくない
最低限下記は知っててほしい

キーワード


■本

プロマネならアジャイルサムライとかチケット駆動開発とかリーン・スタートアップとか読んどけ。頼むから




頼むからこれぐらいは知っといてくれ。確かに流行り廃りがあって、追っていたもの崩壊したときツラいのはわかる。

しかし、上記はもはや流行りでも枯れてきてデファクトスタンダードになっているものばかりだ。

設定ファイルバージョン管理ちゃうとまずいだろとか、本番とは違うからローカル自分で手作業で変えろとか、何言ってんだおまえは。オーケストレーションツール使え。

クライアントが困ってるのに、オマエの環境で再現しねーとかあたりまえだろ。自分環境かえてんだから。同じにしろ

リリース対応20時間かかるとか何馬鹿なこと言ってんだ。10体制20時間とか1リリース予算300万超えかよ。本気かよ。

細かくリリースしろ。まとめんな。だから不具合もでかくなる。文言修正だけで3ヶ月待たせるな。機能の追加と軽微な修正は別だ。

あとエクセルやめろ。最初はいいけどメンテがつらすぎる。バグ管理テスト設計図なんかはもはやそれ用のオンラインツールあるやろ。それ使え。




もう少し最新のヤツは勝手に追え。

俺はそれらがデファクトスタンダードになるかコケるかは責任もてん。

少しだけいうならローカルビルドシステムはあっていいかもな。gulp とか grunt とか。

ログイン ユーザー登録
ようこそ ゲスト さん