英語の歌詞を和訳してブログに書きたいなと思いつつも私のようなにわか音楽ファンが愛好しているような曲は大概誰かしらが和訳していて中々着手できないでいます。
今日またふと和訳熱が上がったので最近よく聴いてるIDLESのNever Fight a Man With a Permの和訳を探して見たところまだ誰も和訳していないようでしたので、恥ずかしながら和訳して見たいと思います。
※和訳がおかしいと感じた方はコメント頂けますと非常に助かります。
続きを読む
vSphere ClientでCVE-2018-3646の脆弱性エラーがでる
直近のVxRailのHCI環境の構築案件で上記エラーが出力されていました。
メッセージを見ると潜在的な脆弱があることが書かれていますが調べていくと対処法が厄介(悩ましい判断を迫られる)なことがわかったので調べた内容を整理しておこうと思います。
実環境のrebuildについては割愛します。
メッセージ内容
このホストにはCVE-2018-3646で記述されている問題に対する潜在的な脆弱性があります。詳細およびVMwareの推奨については、https://kb.vmware.com/s/article/55636を参照してください。
VMware社のkb
KB55636について
まずは素直にメッセージにあるkbを確認します。
https://kb.vmware.com/s/article/55636
L1 Terminal Fault(L1TF)という名の脆弱性について記述されています。
L1TFでは以下3つの脆弱性を上げています。
- CVE-2018-3646 (L1 Terminal Fault - VMM)
CVE-2018-3646 の軽減策では、Intel ハードウェアで実行されているホストに対してハイパーバイザー固有の軽減策を行う必要があります。
- CVE-2018-3620 (L1 Terminal Fault - OS)
CVE-2018-3620 の軽減策では、オペレーティング システム固有の軽減策を行う必要があります。
- CVE-2018-3615 (L1 Terminal Fault - SGX)
CVE-2018-3615 は VMware の製品またはサービスに影響を及ぼしません。 詳細については、KB54913 を参照してください。
CVE-2018-3615についてはVMwareの製品は無視して良さそうです。
CVE-2018-3620については重要度中程度の脆弱性でWindowsやRHELは影響を受けずプリインストールのアプライアンス製品に影響が出ます。HiperVisorには影響なしとの記述があるので、ここでは一旦スルーします。
via:https://kb.vmware.com/s/article/55636
問題はメッセージにもあるCVE-2018-3646に絞り込めました。
上記KB55636の中にある3646の解決策は下記です。
CVE-2018-3646 (L1 Terminal Fault - VMM)
ハイパーバイザー固有の軽減策
VMware は、CVE-2018-3646 用のハイパーバイザー固有の軽減策を提供しています。 AMD プロセッサは影響を受けません。 製品固有の軽減策に関する手順または脆弱性分析については、次のナレッジベースの記事を参照してください。
今回はvSphereで出ているメッセージとなるのでKB55806を見る必要があります。
KB55806について
https://kb.vmware.com/s/article/55806?lang=ja
ハイパーバイザーまたは別の仮想マシンが権限を持つ情報が同じコアの L1 データ キャッシュ内に同時に存在する場合は、特定の CPU コアで実行されている悪意のある仮想マシンによってこの情報の内容が実際に推論される可能性があります。 現在の Intel プロセッサは、ハイパースレッディング (HT) 対応コアの両方の論理プロセッサで、物理的に解決された L1 データ キャッシュを共有します。両方の論理プロセッサでソフトウェア スレッドの同時スケジュール設定を無差別に行うと、情報がさらに漏洩する可能性が生じます。
要約すると複数仮想マシンが同一コアを掴んだ時に悪意のある仮想マシンから別の仮想マシンのL1データキャッシュにアクセスできてしまうというものです。
本来vSphere上の仮想マシンはコアを共有しないのですがハイパースレッティングがハード側で有効になっている環境では1コアが複数スレットに論理的に分割されるため上記にある複数仮想マシンが同一コアを掴むことが可能な状態になります。
上記攻撃ベクトルには二種類あります。
KB55806の解決策について
解決策については3つのフェーズの対応が記載されています。
1:更新フェーズ
シーケンシャルコンテキスト攻撃を軽減するには、VMware Security Advisory VMSA-2018-0020 に記載されている製品バージョンに vSphere を更新します。
- 更新フェーズ： vSphere の更新およびパッチの適用
この軽減策はデフォルトで有効になっていて、パフォーマンスに大きな影響を与えません。
このパッチは最新版のvSphereを適用することで当たっているようなのです。一安心です。
2:計画フェーズ
同時コンテキスト攻撃ベクトルを軽減するには、VMSA-2018-0020 に示されている更新およびパッチに含まれている ESXi サイドチャネル対応スケジューラを有効にします。 デフォルトでは、このスケジューラは有効ではありません。 このスケジュールを有効にすると、vSphere 環境で実行されているアプリケーションのパフォーマンスに大きな影響が及ぶ可能性があります。 計画フェーズの目標は、同時環境に、スケジューラを有効にしても動作に影響が生じないようにするために必要な CPU キャパシティがあるかどうかを把握することです。
- 計画フェーズ： 環境の評価
次のリストに、ESXi サイドチャネル対応スケジューラを有効にした後に生じる可能性のある問題領域の概要を示します。重要： 上記のリストは、ESXi サイドチャネル対応スケジューラの有効化に関連する問題領域の概要を示すためのものです。 VMware パフォーマンス チームは、KB55767 で詳細なガイドおよびパフォーマンス データを公開しています。 スケジューラを有効にする前に、このドキュメントを詳細に確認することを強くお勧めします。
- ESXi ホストで使用できる物理コアの処理能力を上回る vCPU が装備された仮想マシン
- カスタム アフィニティまたは NUMA が設定された仮想マシン
- 遅延の影響を受ける構成の仮想マシン
- 平均 CPU 使用率が 70% を超える ESXi ホスト
- カスタム CPU リソース管理オプションが有効になっているホスト
- ローリング アップグレードによって平均 CPU 使用率が 100% を超える HA クラスタ
注： ESXi サイドチャネル対応スケジューラを有効にする前に、追加のハードウェアを取得するか、既存のワークロードを再分散しなければならない可能性があります。 組織は、リスク評価を行って同時コンテキスト攻撃ベクトルで発生するリスクを受け入れた後に、ESXi サイドチャネル対応スケジューラを有効にしないように選択することができます。 この方法はお勧めしません。VMware が組織に代わってこの決定を行うことはできません。
重要なので長々と引用しましたが、"ESXi サイドチャネル対応スケジューラ"を有効にすることで、同時コンテキスト攻撃の対策になるが、これを実施するとパフォーマンスに大きな影響があるとのことです。
（私が直接確認している訳では無いのですが）
上記対応を社内で検証したメンバー曰く"ESXi サイドチャネル対応スケジューラ"を有効にしたところESXiの物理CPUのスレット数が半分になって起動してきたとのことです。これについては各KBの中で記載が見つけらていのですがこれがパフォーマンス劣化の原因と考えています。
パフォーマンスの影響については下記に詳細が(脆弱性系の調べ物って本当にあっちこっちに飛ばされて辛いです。)あります。
https://kb.vmware.com/s/article/55767?lang=ja
VMware のテストでは、ESXi サイドチャネル対応スケジューラを有効にした結果、ワークステーション、ホスト使用率、およびホスト内で使用されているプロセッサ数に応じて、ホストの最大パフォーマンス キャパシティが 30% 減少しました。 これは、アプリケーションのパフォーマンスが必ず 30% 減少するという意味ではないことにご注意ください。
必ずしもではないもの30%となるとこれは大問題です。おそらくコア数に対する仮想マシンの数がオーバコミットすればするほどにどんどんCPUのwaitが上がってパフォーマンスが劣化すると予測しています。
注： ESXi サイドチャネル対応スケジューラを有効にする前に、追加のハードウェアを取得するか、既存のワークロードを再分散しなければならない可能性があります。 組織は、リスク評価を行って同時コンテキスト攻撃ベクトルで発生するリスクを受け入れた後に、ESXi サイドチャネル対応スケジューラを有効にしないように選択することができます。 この方法はお勧めしません。VMware が組織に代わってこの決定を行うことはできません。
この対応を実施する前に追加のハードウェアを取得しろと書かれています、、、、このトレードオフに素直に従うユーザどれだけいるのか疑問が残ります。
3.スケジューラ有効化フェーズ
計画フェーズで上記の問題領域を解決した後に、CVE-2018-3646 の同時コンテキスト攻撃ベクトルを軽減するには、ESXi サイドチャネル対応スケジューラを有効にする必要があります。
- スケジューラ有効化フェーズ： ESXi サイドチャネル対応スケジューラの有効化
VxRail(EMC)の見解
現在構築中の案件はVxRailを採用しているためEMC側の見解が知りたいところです。EMCも本脆弱性についてナレッジを出しています。
内部VCSA利用環境 VxRailが4.0.520、または4.5.218以上 外部vCenter利用環境 vCenterが6.0 U3hまたは6.5 U2c
上記環境で当該メッセージが出るとのこと。現行バージョンだと出てしまうということです。(VxRailではVxRailのバージョンに紐づいてESXiやVC(内部VCSAの場合)のバージョンが決まります)
概ねVM社のナレッジからの抜粋となっていますので違うところについて。
CVE-2018-3620について
CVE-2018-3620はゲストOSレベルの脆弱性です。
VxRailのサービスVM(VxRail Manager、VCSA、PSC)への対処は、VxRailが4.0.520・または4.5.218以上にアップグレードされた時点で完了します。
お客様の仮想マシンについては、ゲストOSごとの対処を行う必要があります。
外部vCenterをご利用のお客様は、外部vCenterを6.0u3hまたは6.5u2c以上にアップグレードする必要があります。
CVE-2018-3646について
CVE-2018-3646はハイパーバイザレベルの脆弱性です。
対処には、VxRailを4.0.520・または4.5.218以上アップグレードした後、ESXi SCA Scheduler(ESXiサイドチャネル対応スケジューラ)を有効化する必要があります。
ESXi SCA Scheduler(ESXiサイドチャネル対応スケジューラ)の有効化には、CPUパフォーマンスへの影響を伴う場合があります。
3620については解消済みとの記載がありました。
また警告の抑止手順を案内した上で下記の文言で閉じています。
--------------------------------------------------------------------------------------------------------------------------------------
Dell/EMC/VMware のうちどのベンダーも、当該問題についてお客様に取っていただくべき対応方針を案内・推奨・手引きすることはできません。
当該問題により発生し得るお客様ビジネス・セキュリティコンプライアンスへのリスク、及び問題への対処に必要なクラスターリソースを確認いただいた上で、お客様自身で対応方針を策定いただく必要があります。
--------------------------------------------------------------------------------------------------------------------------------------
まとめ
- 本エラーの解決策の対応をするには"ESXi サイドチャネル対応スケジューラ"を有効化する必要がある。
- 対応しない場合はCVE-2018-3646の脆弱性対策はできない。
- 有効化した場合はオーバーコミットしている環境では大きなパフォーマンス劣化の可能性を孕んでおりこれに対応するにはノードを増やしてCPUコア数を稼いでオーバーコミット防ぐ必要がある
そもそもAWSとは(初心者向け)
先日Amazonの売り上げについてここに書きました。
AWSの業績がすごい勢いで伸びているというのはわかりますがそもそもAWSって何なのといわれるとシステム業界にいる私でもちゃんと説明ができないので、これを機に整理したいと思います。
AWSとは
まずはwikiに聞く。
Amazon Web Services - Wikipedia
Amazon Web Services（アマゾン ウェブ サービス、AWS）とは、Amazon.comにより提供されているクラウドコンピューティングサービス（ウェブサービス）である。クラウドのタイプとしてはIaaSに分類される。
IaaSに分類されるとのことです。ん？IaaSって？
引用元：IaaS、PaaS、SaaSの違いを整理して、クラウドサービスの特徴を知ろう | ニフクラ
上記リンクが非常にわかりやすかったので下記に要約します。
IaaS（イアース/アイアース）
「Infrastructure as a Service」
インターネット経由でサーバーやネットワークなどを利用する
代表的なIaaSサービス
- Amazonが提供する「Amazon Elastic Compute Cloud （Amazon EC2）」
- マイクロソフトが提供する「Microsoft Azure」
- Googleが提供する「Google Compute Engine（GCP）
PaaS（パース）
「Platform as a Service」
インターネット経由で開発環境を利用する
代表的なPaasサービス
- 各種プログラミング言語を使用してWebアプリケーションの開発・公開が可能なGoogle App Engine
- Webアプリケーションの開発から実行、運用までをクラウド上で完結できるHeroku
SaaS（サース）
「Software as a Service」
インターネット経由でアプリケーションを提供する
代表的なSaasサービス
Amazon S3はここに分類されるような気もしますが、違うのかな？
AWSにはどんなサービスがあるのか
色々なサービスがあるようですがメインは下記の二つ
AWSの有名なサービスにAmazon Elastic Compute Cloud (EC2) とAmazon Simple Storage Service (S3) がある。
Amazon Elastic Compute Cloud (EC2)とは
Amazon Elastic Compute Cloud (EC2) は、アマゾンが提供する計算資源を用いてアプリケーションを実行する、Amazon Web Services (AWS) の商用ウェブサービスである。アプリケーションのスケーラブル展開が可能で、ヴァーチャルマシンと呼ばれるサーバインスタンスを作成して希望するソフトウェアを実行する。サーバインスタンスは必要に応じ作成、実行および停止が可能で、起動サーバの使用時間に応じ対価を支払うため"elastic"と呼ばれる。サーバインスタンス同士を隔離されたゾーンに作成すると障害時は相互にバックアップとなり、ダウンタイム最小化構成[1]が可能である。
起動時間に応じて課金されるレンタルサーバーをクラウド上で提供しているウェブサービスと言ったところでしょうか。やはり触ってみないとピンと来ないのでタダでどれだけお試しできるか今後調べていこうと思います。
Amazon Simple Storage Service (S3)とは
Amazon Simple Storage Service (Amazon S3) とは、Amazon Web Services によって提供されるオンラインストレージのWebサービス。Amazon S3は、Webサービスのインタフェース（REST、SOAP、およびBitTorrent）を介してストレージを提供している。
有料のストレージサービスですね。専用のダウンローダやWinSCPでファイルをputしたりgetできるようです。
まとめ
AWSには主要なサービスとしてサーバ貸しのEC2とストレージ貸しのS3がある。
触ってみたい。今後はどこまで触れるか調査して実際にいじって行きたいと思います。
(娘の)フトアゴ飼育記録
以前このブログに書いたのですがうちの小学校二年生の娘は爬虫類が大好きです。
(娘の)カナヘビの飼育記録 - kabkabsunshine’s blog
(娘の)カナヘビの飼育記録pt2(ランプの取り付け) - kabkabsunshine’s blog
(娘の)カナヘビの飼育記録pt3(最終回) - kabkabsunshine’s blog
(娘の)カナヘビの飼育記録pt4(奇跡の復帰) - kabkabsunshine’s blog
娘の誕生日に訳の分からぬ商業主義に毒されたおもちゃを買うよりは昔から欲しいと言い続けているフトアゴヒゲトカゲをついに購入する運びとなりました。
フトアゴヒゲとかげを買うにはそれなりの装備が必要ですがカナヘビ用に揃えたものがあったのでそれを使用することになりました。
当初一つのケージで二種類を一緒に買うという案がありましたが、フトアゴにカナヘビが食われるという苦い経験をしている人たちがネット上で散見されたため念のため分けて飼うことに決めました。
可哀想ですがカナヘビは虫かご行きです。とはいえあまりに寒いのでパネルヒータを虫かごように追加で購入し虫かご内も25度くらいには保つようにするなど予想外の出費もあったものの今の所どちらも元気です。
ちなみにケージと虫かごをまたいで激しくフトアゴとカナヘビが興奮している姿をみて。やはり分けて飼育が正解のようです。(動画もあるのですがはてなは動画のアップローダがなさそうなので割愛します)
フトアゴにはソランジという名前をつけました。
ソランジの由来は元々我が家ではフレンチブルドッグを飼っており彼女の名前をビヨンセと命名しておりフトアゴにはビヨンセの妹という意味で、歌手のビヨンセの実妹のソランジェからとりました。
ジェがジに変わっているのは私が間違えて命名しそのまま家族に定着してしまうという取り返しのつかないミスによるものです。
娘は以前からyoutuberというものに憧れを抱いているらしくフトアゴを書い始めたことを契機にyoutubeに動画をアップしたいと言いだしました。
最初はノリノリでやっていたのですが、編集の地味な作業は最終的に私任せになりせっかくの休日のうち半日をこの作業に取られことになりました。。。。
娘がyoutuber気取りでノリノリになってるのには気恥ずかしいものを感じつつ、久々の動画編集とかgoogleの未成年アカウントの縛りとか知れて結構勉強になったのとフトアゴちゃんは10年近く生きるというのでこうして記録を動画で残しておくのも面白いかなと思いました。
ちなみに後ろですごーく小さな音でかかっている楽曲は私が作成したもので以前とある案件で没になったBGM用音源です。
Bow Down and Die(和訳)
先週古い友と再会し一緒にこれまた古い友人で今もなお一線で活躍しているミュージシャンのライブに行ってきました。
ライブを鑑賞し終えた後友人も私もすっかり感化され、俺たちもまたバンドやろうぜ！みたいな感じでスタジオに入ろうよという話になりました。
私も友人ともう一人のメンバーは十年ほど前に社会人になってから1〜2年毎週スタジオに入って、素人なりに曲を作ったりライブを何度かやってみた経験があるものの、所詮は社会人バンド、兎に角演奏技術が酷いのです。どれくらい酷いかというと中学生の軽音同好会のバンドの劣化版といったところでしょうか。
下手なバンドなりにかっこよく演奏する施策の一つとして私の出した一つの解はガレージというジャンルを選択することです。
言い訳に聞こえるかもしれませんが私はフュージョン系やスタジオミュージシャンをゴリゴリに使って作り込んど音より荒削り感のある(いわゆるヘタウマ感のある)楽曲が大好物です。
そんな訳で今週はへんなギアが入っておりガレージ系の音源を聴き漁っていました。
この年齢(42)にもなると聞き覚えのない楽曲よりも耳慣れた昔ながらの好きな曲を聴き入ってしまうのですが、appleのおすすめとかを辿っているうちに惚れ込んだ楽曲がありました。
The Almighty DefendersのBow Down and Dieです。
Live映像がありました。
曲だけ聞いてて気づかなかったのですがライブの衣装をみるとゴスペル的なイメージなのでしょうか？歌っている人なんかみたことあるような、、、、、
The Admighty Defendersとは
バンド名自体知らなかったです。
Wikiを見てみました。情報少なっ！
Almighty Defenders - Wikipedia
The Almighty Defenders is a supergroup consisting of members from the Black Lips and The King Khan & BBQ Show. The band was formed in February 2009 in Berlin, Germany.
なんとBlack LipsとKing Khanの混成バンドのようです。どちらも好きなアーティストな上に一足す一が３以上になったパターンです。
youtubeで色々見ていてBlack Lipsが街中の路上でこの曲をカバーしている動画があって気になっていたのですが腑に落ちました。
Black LipsはアメリカのバンドでKIng Khanはドイツ人なのですがこのバンド自体はドイツで結成されているようです。
レーベルはVice recordsです。2009年リリースとのことですが2000年代のViceはやはり熱いですね。
ここまで読んでくれる好き者な方はBlack Lipsはご存知だと思いますのでKing Khan & the shrinesのお気に入りの曲のyoutube貼っときます。めちゃくちゃかっこ良いです。
13年前にトロントのライブハウスでステージを見たのですがかっこよすぎておしっこちびりそうになりました。その日はMOONWALKと書かれたキャップをかぶっていたのですが、この曲のスキット部分の時にking khanが私のことをみてHey Moonwalk! と呼んでくれたことは素敵な思い出です。 見た目バックグラウンドはインド系っぽいですね。ドイツ人です。ライブに集まったオーディエンスが踊り狂ってて全員汗だくでサウナみたいになってました。こちらもVice recordsからのリリースです。
Bow Down and Dieの和訳
さて本楽曲ですが音源聴いていて全然歌詞が聞き取れなかった(そもそも英語が得意ではないのが大きいですがw)ので歌詞を読んで訳して見ました。
via:The almighty defenders – Bow down and die Lyrics | Genius Lyrics
繰り返しの多い曲なので繰り返しの元部分のみ訳してみようと思います。
※先述の通り私は英語がそんなに得意ではありませんので、英語が得意な方で違和感のある方はコメントいただけると非常にありがたいです。
Does he hold you like i hold you
Will he ever bow down and die
(oh yes he will)
> 俺が君を抱くようにあいつは君を抱くのかい？
>どうせあいつはひれ伏して(あの世に)行っちまうよね？
>世間があの娘のことをなんて言ってても俺には関係ないんだ
>俺が手を差し伸べたら君は俺がいるってわかるのさ
歌詞が少なくレトリックが多用されており短いなりに難しいですが、好きな子に他の男性がいて、お前には俺しかいないぜ！みたいな感じでしょうか？
- provided courtesy of iTunes
- provided courtesy of iTunes
- provided courtesy of iTunes
優待クロスについて
私は株主優待が大好きです。忘れた頃にやってくるあの感じはもらった人のみが知る愉悦があります。
とはいえ国内個別銘柄は去年の一月頃から全く利益がでず損きりを続けて今は積立で保有している銘柄以外綺麗さっぱり手放しています。
(今は米国の指数に連動したファンドに積み立てて行くのがマイブームです。)
株主優待とは
株主優待を実施している会社の銘柄の株を権利付最終日時点で保有している株主には株式を発行している企業よりその会社の製品や、その会社の割引券等が送られてきます。
株主優待の実施頻度は会社によりますが年二回ないしは一回です。
最近では上記の限りではなくQUOカードなどを送ってくる会社が増えています。
私はその会社の特徴のあるユニークな優待が好きなので、QUOカード系はあまり取りに行かないのですが優待の達人達は優待をもらってもはけきれず現金化しやすい優待が嬉しいのかもしれません。
私のお気に入りの優待は下記です(優待が好きな人にとっては言わずと知れた優待界の王様銘柄です)。
株主優待は、優待お食事券（1冊）が年2回もらえます。マクドナルドのハンバーガー・サイドメニュー・飲み物が全て無料で6回分も食べられるので、普段店舗を利用される方にとってはうれしい優待ですね♪
・100株 … 1冊
・300株 … 3冊
・500株 … 5冊
我が家はマクドナルドのヘビーユーザなので年に二回ほど3冊(300株)取りに言ってます。3冊あれば合計18セット食せると言うことになります。体に悪そーですね。子供達はいつも大喜びです。
・OLC
株主優待は、年に1回1DAYパスポート1枚がもらえます。400株以上持っていると、パスポートが年に2回もらえるようになります。優待券は、「東京ディズニーランド」または「東京ディズニーシー」のテーマパークで使えます。
3末は上記内容ですが9末は400株以上にしか優待が出ないので要注意です。
これも娘の機嫌を取るため毎年取りに行ってます。
・イオン
◎オーナーズカードの発行
・100株 … 3％のキャッシュバック
・500株 … 4％のキャッシュバック
・1,000株 … 5％のキャッシュバック
・3,000株 … 7％のキャッシュバック
※半年間で100万円までの買い物に対し、買い物金額に上記の返金率でキャッシュバック
※毎月20・30日のお客様感謝デーはさらにお得（お支払い時5％ OFF特典あり）
※カードは、株主ご本人さまカード1枚・ご家族カード1枚の合計2枚発行
我が家は100株しか突っ込んでいないので3%のキャッシュバックですがそれでも毎回数万円のキャッシュバックがあり実はこれが一番家系の役にたつ優待なのではと思ってます。(キャッシュバックが嫁の懐に入り嫁は喜んでいますが私はあまり実感ないです。)
あとイオンラウンジが使えてジュース飲み放題(とお菓子が食べ放題)なので買い物に疲れた時とか良いです。ただうちの地元のイオンは最近いつ行ってもイオンラウンジが混んでいるのであまり行ってません。
優待クロスとは
さて優待をもらうには先述の通り優待を実施している会社の株式を取得する必要があります。そして取得してから権利付最終日まで株を所有する必要があります。ただし株を買うと言うことは株価が下がって損をするリスクを孕みます。(権利付最終日の翌日はかなりの高確率で株価が下落します)
上記の株価下落リスクをヘッジするの優待クロスと呼ばれる手法です。
株式の取引には大きく二種類あります。
・現物買い・・・株価が上がると得をする取引
・信用売り・・・株価が下がると得をする取引
※株主優待をもらうために必要な取引が"現物買い"です。
"現物買い"、"信用売り"の取引を同時に行うことによりどんなに株価が上下しようと常に利益が相殺され損も得もしない状態が作られます。
この状態で権利付最終日を待つ。これが優待クロス取引なのです！！
簡単でしょ？（色々な友人にこの説明を試みたのですが説明が下手なのかいつも全く伝わりません。）
優待クロスの注意点
・年に二回優待を実施する企業は場合によっては初回と二回めで優待内容が異なるパターンがあります
・逆日歩(ややこしくなるの説明割愛！)が発生する可能性があるため必ず信用売は"制度"ではなく"一般"取引を選択
・"一般"取引が使える企業は限られているので事前に調査する
・取引には証券会社に対して手数料を支払う必要があるので手数料を理解する(手数料の安い証券会社を選ぶ)
・手数料をセーブするため権利付最終日をすぎたら現渡で決済する(こうゆう言葉が出てくるとだんだん拒否反応が出ますよね。本筋からそれるのでここでは説明を避けます)
SBIで優待クロスを仕掛けた場合のコスト
コストは買いと売りの手数料プラス貸株料です。
自分で計算できなくて困ってたらわかりやすい表にまとめてくれている人がいたので拝借です。(あってるか検証してません。細かいことを言わないのが男と言うものです。)
※上記は20日前に仕込んだ場合の試算のようです
なので例えば上記にあげた三銘柄の場合、、、
・日本マクドナルドの場合
取得費用：株価4760円(2019/2/7現在)*300株=1428,000円
コスト： 4879円(表の中で繰り上げ)
優待価値：1set600円*18食=10800円
とまあざっくり計算ですが約6000円程度のお得。
・イオンの場合
取得費用：株価2236円(2019/2/7現在)*100株=223,600円
コスト： 1449円(表の中で繰り上げ)
優待価値：嫁いわく=15000円〜20000円
とまあざっくり計算ですが約13000円以上のお得。
・OLC
取得費用：株価11605円(2019/2/7現在)*100株=1160,500円
コスト： 4879円(表の中で繰り上げ)
優待価値：パスポート1枚=7400円
とまあざっくり計算ですが約2500円くらいのお得(表の中で繰り上げすぎてるのでもうちょっとお得かな、、、、、)。
最後に
再三書いておいてあれですが、賢明な読者ならお気づきでしょうがこの手法は株を発行している会社に対して一切の貢献もありません。本来あるべき姿としては応援したい企業の株を購入し企業にお金を上手に使ってもらいさらなる利益を企業から還元してもらうというの本道です。
また機関投資家たちは株主優待を嫌う節もあります。彼らは割引券など欲しておらず欲しいのはお金だからです。なので配当で還元する企業に投資すべきと言う考え方もあります。
とはいえリスクなく優待がもらえて株取引の練習にもなるので株初心者がはじめに試し打ちのような感じでこの手法を試してみるのも入り口としてはありかなと思ってます。すごく勉強になります。
私のバイブルです。
↓
AWSの売上の比率
先日はてなブログで下記のエントリーを読ませていただいて一個私の認識違いがあったので自戒の念を込めて書いておこうと思います。
投資の観点ではリョウスケさん程掘り下げて調べてはいないものの割高すぎて今は買うかが悩ましいと言うのが正直なところです。
とは言えAWSの成長については似たような業界で日銭を稼いでいる立場として見過ごせないものがあります。
さて冒頭にあった認識違いですがamazonの商いの比率です。
AWSの小売の通販業の比率を超えていると勘違いしていました。
上記にある決算データをみてもまだ小売が主戦力のようです。
下の売り上げの比率のグラフが分かりやすいの拝借させていただきます。
そんな中、アマゾンの事業の中で獅子奮迅の働きを見せているのが「AWS」です。
売上ベースで見ると、全体の「10%」程度に過ぎませんが、「AWS」の利益率は、今期26.48%という、非常に高い数値となっております。
※けんさん すみません。情報間違ってました、、、、
とはいえMicrosoftのAZURE然りAmazonのAWSはどちらも抜群の伸びを見せていることは揺るぎない事実です。
私の職場はサーバーハードウェアやストレージ・ネットワークハードウェアを販売してその販売費用・構築費用・保守費用を生業としているため脅威でしかありません。
(とはいえ適材適所といいますかクラウド上でのサービス運用がハマるパターンとはまらないパターンはあるようでクラウド移行したお客様がオンプレスミス(自社で運用する物理ハードウェア)に戻したいと言う引き合いも思った以上に出てきていると言う事実もあるのですが）
それと何よりも恐ろしいのが高い技術力と仕事に対して異様にモチベーションの高い、いわゆるエースと言われる人材が立て続けにAmazonにヘッドハンティングされていっています。その後Amazonで楽しくやっているか、水が合わず旧来型企業に戻っているかは追えていませんがクラウドの潮流が太くなってきていることはもはやごまかしようのない事実です。
クラウドにオンプレスミスが取って代わられると言われて久しいですが、そんなに極端にこれまでのやり方が一気に変わることはないと考えています(だっていまだに汎用機が残ってるなんて十年前に全く想像していいませんでした。)が、大きなパラダイムシフトがついに表面的なお金の数字に顕著に現れてきています。
恐ろしさとともにワクワクが否めません。何回かトライして毎度忙しさを言い訳に諦めてきましたがAWSについてインフラエンジニア目線で徐々に知識を深めよう思ってます。
