Newspeakってどんなバンド？
圧倒的才能が開花する！！
Newspeakを見逃すな！！
ということで、今回は令和を席巻すること間違いなしのバンド「Newspeak」を
紹介します。
- Newspeakの概要
- 他の追随を許さない圧倒的な完成度
- 今後の活動
１．Newspeakの概要
2017年に結成したバンドで、メンバー4人はリバプールから帰国して結成された。
結成されたその年にサマーソニック2017などの
大型フェスに続々出演するモンスターバンド！！
リバプールにいたこともあり、UKロックへの影響を感じるその音楽性が
非常に話題になっているバンドです。
２．他の追随を許さない圧倒的な完成度
彼らの音楽を一度聴けば、衝撃を受けることは間違いないでしょう。
UKロックでみられるような上質なグルーブ感と、圧倒的な世界観に支配され、
そしてこの音楽を作ったのがまだ１０代の少年だったということに、畏敬の念を
覚える、それほど規格外の完成度が彼らの特徴です。
Newspeak - Lake (Official Music Video)
数年前にMrs.GREENAPPLEを聴いたときは、
遠からず日本の音楽シーンを代表するバンドになるだろうと感じましたが、
このバンドはそれどころか世界の音楽シーンに殴り込むことが
できるのではないかと思ってしまうほどのクオリティを誇っています。
また、圧倒的音楽性と、英語詩であることから流されていますが、
歌詞も十分に魅力的です。
Newspeak - Monetized Love (Official Lyric Video)
３．今後の活動
今年も精力的に活動するようですが、大型のフェス出演は今のところないようですね。
ただ、名古屋で開催するTREASURE05Xというイベントはnewspeak含め、
ブレイク中のバンドが多数出演するので要チェックです！
『TREASURE05X 2019』名古屋CLUB QUATTRO公演出演決定！
AWS Batchの注意点
ということで今回はAWS Batchで実際にシステムを構築したときの
なんやかんやについて解説します。
お品書きは以下です。
１．AWS Batchの概要
まずAWS Batchについて、
AWS Batch を使用することにより、開発者、科学者、エンジニアは、数十万件のバッチコンピューティングジョブを AWS で簡単かつ効率的に実行できます。AWS Batch では、コンピューティングリソース (CPU やメモリ最適化インスタンスなど) の最適な数量とタイプを、送信されたバッチジョブの量と具体的なリソース要件に基づいて動的にプロビジョニングします。AWS Batch を使うと、ジョブを実行するためのバッチコンピューティングソフトウェアやサーバークラスターをインストールしたり、管理したりする必要がなくなります。
ということで、大量のデータをさばくことが可能なコンテナサービスです。
AWS Batchのサービスとして提供されるのは
・ジョブ定義
・ジョブ
・ジョブキュー
・コンピューティング環境
https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-batch-2019/
上記の図のとおり、コンピューティング環境はコンテナなので
コンテナイメージを格納するECR、およびECSが別途必要になります。
基本的に実行モジュール(JARファイルなど)はEFSかS3において、
コンテナ作成後にコンピューティング環境にダウンロードするのが
ベストプラクティスのようです。
※上記の図は実行後のOutputとして記載しているので別の話です
２．AWS Batchのメリット
AWS Batchのメリットは、なんといっても大量データを並列して処理できる
という点につきます。（そのためのサービスですし。。）
ジョブキューに入れれば、その数に応じてコンテナが立ち上がるため
よくLambdaと比較されますが、Lambdaと異なり
コンピューティング環境を自分で設定でき、15分の制約もありません。
そのため、Lambdaではできない重い処理を行うときにも
選択肢にあがります。
今回、私がBatchを採用したのは以下の理由からです。
・基本的にそこまで重い処理ではないが、
inputのサイズがリクエストにより異なるため、
Lambdaを採用しにくい（制約にひっかかる不安があった）
・時間によってリクエストの波があるため、
柔軟なスケール性能が求められた。
・秒間数千を超えるリクエストが想定された。
また、リクエストによりinputのサイズが異なるため、
コンテナによって処理が軽すぎたり重すぎたり、といった事象を緩和するため
下記の構成にしました。
SQSにはinputとなるデータのパスとサイズ情報を格納し、
Lambdaはそれをもとに一定数のリクエストを一つのジョブに成形し
AWS Batchのジョブキューに登録しました。
これにより、各コンテナの負荷が均一になり、安定した性能と可用性が
実現できました。
※ちなみにFargateという選択肢もあったのですが、SQSに取得しにいったあとに
ScalingができるのかがわからなかったのでBatchを採用しました
３．AWS Batchの注意点
さてさて、上記でAWS Batchの良さについて説明しましたが、
実装にあたり、結構こまったこともあったので紹介します。
・Time Outで終了した場合、リトライされない
AWS Batchはジョブが異常終了した場合、基本的には設定回数リトライされますが
TimeOutになった場合はリトライが発生しません。
そのため、運用回避するか、リトライアウトの時間を延ばすか、別途Lambdaで
TimeOutをキャッチして積みなおすような処理が必要になります。
・Cloudwatchのロググループを指定できない。
AWS Batchはロググループをこちらで指定できず、すべてが
/aws/Batch/に格納されるため、運用ルールにうまくはまらない場合があります。
・ECSがEC2hostのみでFargate対応していない
AWS Batchのコンピューティング環境ではFargateが指定できません。
そのため、ネットワークなど結構気にしなければいけない場合があります。
・ジョブキューは文字数制限がある。
まあSQSもあるので当たり前ですが。。
設計によってはひっかかるので気を付けましょう
直感は正しい？間違っている？ 直感との向き合い方を考える
TEDというサイトで下記の動画を観たのでそれについて少し記述しようと思う
3 lessons on decision-making from a poker champion | Liv Boeree
動画の概要を3行で
・運は自身の能力を見誤る原因となる。特に少ない経験で見誤りやすい
・事象の確率を数値化することで自身の状況を正しく理解できる
・直感は無視できない、しかし過信してはいけない
ポーカーという運の要素が非常に強い世界で結果を残しているだけあって
非常に説得力を感じた。ので、少し調べてみた（ググっただけ）
すると、直感に関する記事が大量にみられたのでいくつか取り上げよう。
■直感的な戦略決定を行う脳のメカニズムを解明
https://www.riken.jp/press/2015/20150421_1/
理研と富士通が共同研究で棋士の直感のメカニズムを解明するという
研究のプレスリリースだ。
一見するとTEDの主張と逆転しているようだが、Liv Boereeは
"経験の少ない事象で発生した直感は信用ならない"
と述べている。
それに対して棋士はほとんどが幼少から棋譜を眺め、対戦を続けてきた。
すなわち非常に豊富な経験に裏付けられた、"無視すべきでない直感"だと
いえる。
しかも81マス40コマのみで、想定外のリスクが排除された環境である。
一方でこういった記事、というか論文も見つけた。
■Creativity: Intuitive processing outperforms deliberative processing in creative idea selection
https://www.sciencedirect.com/science/article/pii/S002210311730118X
「クリエイティブなアイデアは熟考よりも直感が優れている」
簡単に言うと、直感的に提案したアイディアのほうが熟考したアイディアよりも
専門家からクリエイティブだと評価された、という内容の論文だ。
そもそも専門家が言えばそれがクリエイティブなのか、とか、
被験者の数が妥当なのかなど色々あるのだが、一旦それについては議論しない。
これは先ほどの将棋と違い、経験が少ない"過信してはいけない直感"だろう。
ではなぜそれらが評価されたのか？
推測するに、おそらく"実現性が低い、希望的観測を含んだアイディア"だった
のではないだろうか。
それらは、実現性を正しく理解した専門家たちには無意識に思考の外に
してしまったアイディアだったが、専門家の豊富な知識で思考すれば
非常に良いアイディアだったのではいだろうか。
そして熟考群では直感的なアイディアの実現性を自分なりに評価して、
無知ゆえにできないと判断し、捨ててしまったのではないだろうか。
さてさて、これらをすべて踏まえて総括すると、
直感への向き合い方が見えてくる。
私たちが直感を得たとき、まずすべきことは直感が発生した事象に対して
十分な経験を持っているか、ということだ。
もし豊富な経験があるのであれば、その直感を信じ、裏付けるために動けばいい。
そして経験がない場合、すべきことは捨てることではない。
経験がない場合、その直感を正しく評価できる経験者、専門家の意見を聞くことだ。
経験が少ない以上、直感は信頼できない。
しかし、それを無視するのではなく、客観的に評価する手段を考えることが
重要なのである。
「直感」というのは基本的に無意識化で取得した情報をもとに得られるものであり、
それの原因を理解するのは困難である。TEDではその解決として”数値化”が
挙げられていたが、経験が少ないとそれすらできないこともあるだろう。
そうしたときに、直感を冷静に評価する手段を持つことで常に正しく
直感と向き合えるのではないだろうか。
AWS Lambdaのキホン
AWS Lambdaのキホン
この記事ではAWS Lambdaについて簡単に説明をしていきます。
が、その前に最近AWSを触り始めた方に声を大にして伝えますが、
こんな記事を読まずにBlack Belt Online Seminarを見ろ！
それくらい必要な情報が網羅的に説明されているので、基本はそれを見ることからです。
まあ、それはそれとして以下が本日のお品書きです。
- "サーバーレス"を信用しすぎるな
- イベントトリガーによって変わる並列度
- LambdaとEC2の使い分け
"サーバーレス"を信用しすぎるな
まず、Lambdaというサービスについてですが、AWSが提供するサーバーレスアーキテクチャサービスです。
要するに、サーバの管理やスケールアップやスケールアウトを意識しなくても、
AWSがやってくれるよーっていうサービスです。
しかし、
実際は裏側でサーバが動いていることを
意識しなければなりません。
例を出しましょう。
たとえば処理の途中で中間ファイルを作成する必要がありました。
しかしアプリはLambdaなので次の処理のときには別の関数になり、別のサーバが建つから中間ファイルを削除する必要はないと削除処理を実装しませんでした。
⇒ ディスク枯渇で大量のエラーが出ます
これは、Lambda関数が起動するたびに、裏側でVM（EC2）が用意され
プロセスが起動して実行されるのですが、
数分以内に再度Lambda関数が呼び出された場合、
同じVM（EC2）で処理がされます。
そのため、同じEC2で何度も中間ファイルが作成され、エラーが発生します。
これと似たようなことがRDSへのアクセスでも起こります。
Lambdaは複数呼び出された場合、その分だけプロセスが立ち上がります。
それらすべてがRDSに接続しにいくことによってコネクションプールが枯渇します。
サーバーレスだなんだといっても、裏側は常にサーバが立ち上がって
処理を行うことを意識しましょう。
AWSが言う"サーバーレス"とは、
「実行するサーバの準備や、OS、ミドルウェアの管理を私たちがやります」
という意味でしかありません。
Lambdaの特性を理解したアプリケーションの実装はユーザ側で
検討が必要なのです。
イベントトリガーによって変わる並列度
Lambdaにはイベントトリガーという機能が存在します。
例えばS3のデータが作成、更新されるたびにこのLambda関数が呼び出される、
ということを数クリックで設定できるのです。
しかし、このイベントトリガーの機能は複数の種類があります。
同期呼び出し、非同期呼び出しなどなどあるので、
自分が使うトリガーが何にあたるのかしっかり把握しましょう。
※エラー発生時の挙動も変わります。
ここではその詳細は割愛しますが、それぞれのトリガーでLambdaの同時実行数が
どのようにかわるのかを解説します。
１．無制限の並列実行
基本的にはこれが多いでしょう。S3やSQS、APIGatewayがこれにあたります。
１つのリクエスト（通知）に対して処理が実行されます。
これの注意点は２つです。
・パブリックIPが枯渇するほどの多量実行がないこと
・同時実行時のデータ不整合について検討すること
まずパブリックIPですが、先ほども言ったように裏側ではVM（EC2）が立ち上がります。
これらは、設定しなければパブリックなネットワークに立ち上がるため、
パブリックIPが割り当てられます。そこで数百、数千とVMが立ち上がると当然
パブリックIPが枯渇し、これ以上実行できないという事態が発生します。
次に、同時実行時のデータ不整合ですが、
これらはすべて重複して発生する可能性を考慮する必要があります。
要するに、一つのイベントに対して複数の関数が実行されるのです。
（APIGatewayはちがうかも。。）
そのため、データを取得後、削除する場合は、そのあと別の関数がデータを
見に行って存在しない、などの事態が発生することを考慮しておく
必要があります。
２．シャード数に応じた並列実行
これにあたるのは、Kinesis やDynamoDB Streamsです。
これらは、kinesisに投入されたレコードの数だけ関数が立ち上がるのではなく
シャード数の数だけVMが立ち上がり、１秒ごとにデータを取得して
処理を実行します。
kinesisの場合、1度で6MBまでのデータをリスト型で取得します。
kinesisについては、シャード数をコンソールで簡単に設定できます。
DynamoDB Streamsはパーティション数に基づいてLambdaが起動するのですが
ぶっちゃけ使ったことないのでよくわからん！！
３．単一で動くイベント
Cloudwatchイベントによるスケジュール実行などがこれにあたります。
なので、定時バッチ処理を並列に動かしたいときは、
Cloudwatch ⇒ Lambda（シングル） ⇒ Lambda（並列実行）
など、一工夫加えてやる必要があります。
さいごに、いろいろと言いましたが、Lambdaサービス自体は非常に有用な
サービスで、最も使う機会が多いです。
特性を理解して使えば低コストですばやくアプリ開発ができるので
うまく付き合っていきましょう。
EMRでSparkをつかうときの注意点
業務の関係で、EMRで上にSparkを載せたシステム構築によくかかわっているので、
その中でつまったところなどについて記載してみました。
※本稿はHadoopやSparkに関する最低限の知識が必要です
１．EMRとは
まず、そもそもEMRについて簡単に説明すると、AWSのサービスでビッグデータ分析を簡単に実装することができるサービスのことです。
2019/09/01時点
■正式名称：ElasticMapReduce
■対応OSS：Hadoop, Spark, Hive, HBase, Phoenixなど
■AWS コンソール上でUIを使って簡単にクラスタ構成を作成できるサービス
■最近Masterノードのマルチ構成にも対応した
https://docs.aws.amazon.com/ja_jp/emr/latest/ManagementGuide/emr-overview.html
■料金体系はEMR料金＋利用したVMの料金
⇒ クラスタ作成時にVMが割り当てられるので使った分だけ支払うサービス
２．オンプレとEMRは何が違う？
Sparkに関する説明は省きます。また別の記事で説明するかもですが。。
では、SparkをオンプレからEMRに変更したときの注意点を記載していきます。
①HDFS上のデータが消えてしまう
オンプレと異なり、Sparkを利用した後EMRを削除すると、
利用していたVMがすべて消えてしまいます。
そのため、最終的なOutputデータはもちろん再利用したい中間データなども
VMのディスクではなくS3に格納する必要があります。
つまり、一度取り込めば使えるデータもクラスタ作成のたびに取り込む必要があります。
②IPアドレスが毎回異なる
どのマシンにどんなIPアドレスが割り当てられるのかわかりません。
そのため、PhoenixテーブルなどMasterノードにSlaveがアクセスするときに
静的IPアドレスを利用してアクセスしにいくことができません。
③OSSのバージョンがEMRのバージョンに依存する
EMRバージョンによってSparkなどのバージョン決められています。
そのため、オンプレで利用しているSparkのバージョンと同じものが入っている
EMRのバージョンを指定する必要があります。
④追加のソフトウェアなどはブートストラップアクションでインストールする
EMRでSparkを利用してデータ分析を定期実行を実践する場合、datapipelineなどでEMRのステップ実行を利用することが多いです。
その際クラスタの作成からモジュール実行まで止まることなく進む必要があります。
そのため、VMに乗り込んで環境構築ができないため、
ブートストラップアクションで環境構築のスクリプトを準備します。
また、特に指定なき場合、ブートストラップアクションはすべてのVMで実行されます。
以上、オンプレからEMRに移行する際にひっかかりがちなところを記載してみました。
他にもいろいろあるので、適宜更新していきます。
うつ 心との向き合い方
「うつ」って結局のところ何だろう？
皆さん、こういったことを考えたことはないでしょうか？
周りの人がうつや、ストレス障害、不安障害になったときに
いろいろ調べてみて、よくわからなくなった、どうすればいいか
わからなくなった、そんな人に読んでいただければ幸いです。
1.そもそも「うつ」とは
2.病院に行くことは特別なことではない
3.さいごに
1.そもそも「うつ」とは
うつとは、心の病気ではありません
世間一般的にも、専門分野の人も、よく「心の病気」と
表現しますが、大間違いです。
なぜなら、
「心」なんてものは体のどこにもないからです。
私たちが持っているものはいつでも体ひとつです。
心も、魂も存在することはありません。
（少なくとも現代医学では）
つまり、
うつとは、体の病気なんです。
自分がうつだと疑っている人も、周りにうつ病のような人がいて、
心配されている方も、まずはこれを忘れないでください。
では、体のどこが悪いのでしょう？
おそらく、皆が一斉に答えられるでしょう。
そう、脳の病気です。
病気というと重く聞こえるので、マイルドにいうと
脳の体調不良です。
（まあ、死に至る場合もあるので非常に重い病気なのですが。。）
さてさて、それを理解してもう一歩踏み込んで「うつ」と「風邪」を
比較して考えてみましょう。
・風邪の場合
⇒ 免疫力が弱っているときに、細菌が体に入り込むことで
体調を崩して風邪にかかりやすい。
・精神疾患（うつ、不安障害など）の場合
⇒ 精神的に不安定（脳の神経伝達が不安定）なときに、
過度なストレスをうけたときに脳の神経伝達で
異常が発生し、発症しやすい
※大うつ病障害を含め、うつの原因はまだ解明されていません
ただし、脳神経系が深く関連していることは多くの研究で示唆されています
すごく良く似ていますね。どちらも体が弱っているときに
外的要因（ストレス）によって発症します。
※広義には、外的要因を広くストレスと呼ぶので、細菌による
細胞への負荷もストレスの一種です
しかし、次に大きな違いがあります。
風邪の場合は、高熱によってストレスの原因である菌を排除することができますが、
精神疾患の原因となったストレスを排除することは
とても難しいです。
これが、うつを含めた精神疾患が再発しやすい
最大の要因であると考えられます。
風邪の原因である菌を殺しきれず、風邪がぶりかえすように
精神疾患もぶり返すのです。
逆に言うと、どのストレスが原因で発症したのかがわかれば、
それを取り除けば自然に快方に向かいます。
仕事で発症したのなら、仕事そのもの、あるいは職場を変える
家庭で発症したのなら、別居や引っ越しをする
といっても、変えたことで別のストレスを抱えたり、
複数の要因が絡み合っていたりすることもあるので
すぐに治らない場合も多いです。
結局、どうすればいいの？と言われると回答は難しいのですが、
まずは
自分のストレスの原因が何なのかを
しっかりと把握しましょう
そのうえで、どうやって排除すればいいのかを考えるのです。
2.病院に行くことは特別なことではない
さて、前の項で下記2点をお伝えしました。
・うつは「心の病気」ではなく「脳の病気」
・ストレスの原因を明らかにすることが重要
この２つを踏まえて、体調をよくするために必要な
・脳の状態をよくする（一時的対処）
・ストレスを分析し、取り除く（恒久的対処）
を手伝ってくれる場所があります。そう、病院ですね。
ここで、そもそもなのですが、多くの人が精神的なことで
病院にいくことに消極的です。
それは
「自分の心が弱い、傷つきやすいだけで病気ではない」
「自分はおかしくない、異常者ではない」
といった思考によるものです。
この根本にあるのは、
「心の病気」という言葉による誤解、偏見による
ものだと考えています。
心の病気と言われた瞬間、自分自身の性格や考え方、それこそ心を否定される
ような気がしてしまうのではないでしょうか。
しかし、それは大きな勘違いです。
「脳の病気」なのですから、
脳の神経系が治れば解決する話であって、
病気になったからといって
あなたの人間性、性格が否定されることでは
ありません
風邪と同じように、「最近調子が悪いんです」と気軽に病院に向かってよいのです。
私に言わせれば、「うつ」が重くとらえられているのは、
多くの人が重症化してからしか病院にいかないことが原因です。
自分ではどうにもならなくなって思い詰めてから
病院に行くのは、風邪をこじらせて肺炎になって
４０度の高熱がでてから病院に行くのと変わりません。
体調が悪いと感じたら、早めにカウンセラーにかかりましょう。
ここで、よくある選択肢として下の二つがあります。
・心理カウンセラー
この二つは自身の状態とやりたいことから使い分けてください。
まず、一時的に脳の状態をよくする＝薬は、病院でしか処方されません。
時間がたてば解決する、あるいはすぐに効果が出ないと
いけない状態であるなら
病院に行って薬をもらうとよいでしょう。
一方で、どれくらいストレスがかかっているのか知りたい、
ストレスの原因を突き止めたいといった内容なら、
あなたの話を親身に聞いてくれる
心理カウンセラーのほうが適切かもしれません。
また、
心理カウンセラーは心理学の専門家ですので、
ストレスのかかりにくい考え方などについても
アドバイスをくれます。
風邪でいうところの、健康的な生活習慣を教えてくれるような感じですね。
こうしたカウンセリングで、自分のストレスの原因とその対処について
相談しましょう。
また、病院でもカウンセラーがいる場合や、
医師そのものがそういった知識や資格を持って
親身に聞いてくれることもあります。
カウンセリングがうまくあなたとマッチするかは運も大きいので
いくつか受診してみて、あなたが好感をもてる医師、カウンセラーを探しましょう。
続きを読むズーカラデルってどんなバンド？
2018~2019年大ブレイク中！
ズーカラデルの魅力を徹底解剖！
さて、みなさん2019年人気急上昇バンド、ズーカラデルをご存じでしょうか？
ズーカラデルについて今回の記事では紹介します。
1.概要
2.彼らの魅力
2-1.「日常」を切り取る音楽性
2-2. 穏やかなのにダンサブル
3.2019年活動予定
１．概要
- 北海道出身３ピースバンド
- 2019年7月10日 1st full album「ズーカラデル」リリース
- 今年は全国ツアー＋有名フェス出演で一層露出が増える！
個人的にはtacica以来久々の北国発ロックバンドの登場です！
北海道は定期的に質の高い刺客を送り込んでくるので油断ならないですね。。
※公式サイトリンク
2.彼らの魅力
2-1.「日常」を切り取る音楽性
彼らの魅力はもうこの一言に尽きます。
かっこつけたエフェクトも、言葉も使わず、
冴えない彼らの冴えない言葉が軽快なメロディーに乗って
私たちの耳まで届いてくるのです。
ズーカラデル "漂流劇団" (Official Music Video)
右も左も地獄の入り口 どうしてこんなところにきた
惰性の吐息でお茶を濁している
今からこの世界がひっくり返らないかな
客席はガラガラのまま また次の幕が上がる
と、何もうまくいかないような言葉を並べた次の瞬間、
あなたを笑わせたいのだ 歯の浮くような台詞並べて
と、力強く歌い上げる。
この躁うつ病かと思うほどの感情の振れ幅にも関わらず、
共通して軽快な音楽が流れているのが非常に特徴的ですね。
些細なことで喜んだり、落ち込んで死にたいと口に出しつつ、
実際にそう思っていても、大体の場合は、結局次の日が始まるような
そんな「普通の冴えない日常」を描き出してくれる、そんなバンドです。
極端な絶望や暗さもなく、かといって底抜けに明るいわけでもない、
大層な哲学を語ったりもしない、
だけど不思議と元気をもらえる音楽が最大の魅力なのではないでしょうか。
2-2.穏やかなのにダンサブル
上に掲載した「漂流劇団」を視聴された方は
感じることができたのではないでしょうか。
そうです、ズーカラデルの楽曲は基本的に穏やか、というか
うるさすぎないような印象を受けるのですが、その一方で
思わず踊りだしたくなるような楽曲が多いのです。
いわゆるクラブで踊るようなダンスではなく、
芝生で笑いながらくるくる回るような楽しさがたまらないですね。
ズーカラデル "ダンサーインザルーム" (Official Music Video)
3.2019年活動予定
2019年は非常に精力的に活動するようで、
まず何といっても
全国ワンマンツアー！！
さらには、
ROCK IN JAPANやRISING SUN、
有名フェスに参戦予定！！
今後、躍進間違いなしのズーカラデルは見逃せないですね！
ちなみに、最後に、、
ボーカル 吉田さんのソロ楽曲も最高なんだぜ、、、
