2018年半年終わって取引感想
2018年上半期は主にドル円とWTI原油CFDに絞って取引した。
2018年3月頃に104円台でのLを幸運にも拾い、ピラミッド建設で
中々の利益を出すことができた。
原油は、基本的には長期は持たないで短期決済で回転していくのが上手く当たった。
ドル円、原油ともに良い成績だった。
季節は早めに梅雨を終え、いよいよ夏の真っただ中に突入する中で、W杯が終わりを迎え、ドル円も112円まで上昇した。
少し新しい展開があるのかな、と思っている。
最近気になっていることは、アメの長期金利が3%を超えられないこと。うーん。
まあ兎に角、春先から持っていた大きなポジションを解消したので、これからどう動くかを見る時期か。
原油はちょっと読めないが、75ドルはもう中間選挙まで超えられないだろうという気はするので、
レンジを意識しつつ大きいポジションで買いを狙うのは年後半あたりからな感じ。
ドル円は様子見つつ、適度に参加していきたい 。
Azure AppService上のサイトへのリバースプロキシで苦しんだ話
以下の構成でサービスを運用している。
クライアント - リバースプロキシ(nginx) - Cloudservices
バックエンドをCloudServices → Azure App Serviceに置き換え、以下のように構成しようとした。
クライアント - リバースプロキシ(nginx) - Azure App Service
CloudServicesと異なる点は、AppServiceでは単一IPで複数のWebサイトをホストしていることだ。 (しようとしている )
IP固定も可能だけど。
AppService plan料金
Isolatedで、月3万円ぐらいかな。
クライアントからのリクエストURLはリバースプロキシのURLで変わらないので、リバプロで AppServiceの各サイトへの振り分けを行ってあげる必要がある。
Azure App Service の リージョンとスタンプ、IP アドレスについて
Azure App Service ではサイト固有の一意のパブリック IP アドレスは割り当てられていません。 したがって、Azure App Service では、IP アドレスや TCP ポートに一意性はないため、ホストヘッダー (サイト名、または、カスタム ドメインを構成している場合はドメイン名) を使用して HTTP 要求のルーティングをする必要があります。
と書いてあるように、ホストヘッダを指定して振り分けるしかなさそうである。
nginx的にはこんな感じ。
server { listen 443 ssl; server_name testproxy.com; location /a { proxy_pass https://XXXXXXXXXX(AppServiceのIP) proxy_set_header Host test1.com; proxy_redirect default; } location /b { proxy_pass https://XXXXXXXXXX proxy_set_header Host test2.com; proxy_redirect default; } }
これで、リクエストはAppServiceに転送できるが、問題はバックエンド(AppService上のtest1.com、test2,com)で Hostヘッダを見てなんかやっている処理があったりする場合。
にも書かれているが、通常リバプロでは proxy_set_header Host $host; とか設定して、クライアントから渡された、あるいは設定されていなければserver_nameから取得した値を Hostヘッダに指定する。と思う。
今回はHostヘッダを(強引に)指定してプロキシしているために、バックエンドで問題が起こる可能性がある。(リダイレクト時など)
リクエストURLを取得する(ASP.NET プログラミング)
↑とか。Request.Urlプロパティから値を取得するのだが、内容はHostヘッダから組み立てている模様。
Application Request Routing (ARR) を使う場合に必ず設定しておきたい項目
アプリケーション側で Host ヘッダを見て URL を組み立てる場合に、プライベート IP アドレスがホストになってしまうことがあります。特に ASP.NET の Request.Url でこの問題が発生します
上記のようなことである。
- バックエンドのアプリのHostヘッダを見てる処理に手を入れる
- AppServiceプランをIsolatedにしてIP固定にする。(どうやら、Isolatedプラン以外では例え1サイトのみの構成にしてもHOSTヘッダは指定する必要がある)
結局、この2点の何れかにすることになった。 nginxで色々頑張る(リクエスト見ていろいろ書き換える)も検討したが、それはなんかちゃう、という気がしたのでやめた。
しかし、こういう用途(リバプロ + 単一IPで複数ホスト)ってほとんどWeb上の情報がでてこない。
詳しくないのでわからないが、この用途自体がおかしい(珍しい)のか……
サポートに聞いたらnginxでの構築事例は聞かないが、普通にAppService上にプロキシ立てて、そこから
AppServiceに。みたいなのはあるらしい。
というかパスで振り分けるだけだったらApplicationGateway使えばええやね……
Azure Application Gateway の概要 | Microsoft Docs
nginxは時々触るが毎回苦しめられるので、記憶に定着するように形として残していきたいものである。
参考URLまとめ
HTTP のリダイレクション
リバースプロキシーと HTTP リダイレクト
ホストヘッダー
AzureWebAppsのSSLでドハマリ
Application Gateway の複数サイトのホスト
HTTP 1.1のHost:ヘッダーの保持
リダイレクト
AmaWeb設計&開発ガイド第一章
AmazonWebServices設計&開発ガイドを読み始めた。
第1章から。
AWSのメリットや、オンプレミスに対しての優位性についての説明。
パトリオット法が失効していたのは知らなかった。
セキュリティ的には、もちろんそれなりの自社サーバールームよりAmazon様のデータセンターのほうが万全のセキュリティで安全だというのは耳タコな話ではあるけれど、責任共有モデル(OSより上のレイヤーは利用者が責任をもって管理する)で、
自分としては何回かやらかしているので、安全か、といわれるとうーんとなる。(まあ、自分が悪いんですが。オンプレでは起きないようなことも逆に起こる)
クラウドを使うことに抵抗なくなってくると、複数クラウドからのサービス選択が
今後のスキルになっていく気がする。
Azureは何だかコンソールが好きじゃない。
ということで、そろそろAWS Solution Architecht Professional を取得したいので、朝早く起きて勉強したいと思う。
難しいのは勉強じゃなくて、朝起きることだが……
fifa18キャリアモード
目標とか色々たてなきゃなーとか思ってた新年だけどここまでfifa18 switch版をやっているばかりで何にも考えてない
目標とか考えるのは苦痛。特に自発的でないときは。
目標とかキャリアプランとか怠い。
レジェンドレベルのfifaは難しい。
ニューカッスルでの成績
1年目:38試合10勝8分20敗 26得点51失点 16位
2年目:27試合8勝11分8敗 31得点35失点10位
途中解任された……ショックすぎる
エニアグラム簡易診断とかいうのやったら 「平和を好む人」だった。
エニアグラム 〜9つのタイプ 性格の特徴、世界観、動機、行動スタイル、エッセンス(本質的資質)
穏やかで、人に安心感を与え、気持ちをなごませる。人から見捨てられることを恐れ、平和や快適であること、また、一体感を好む。健全な状態で、平和で安定した心を保つ。周囲に緊張や葛藤がある場合は、公平な立場で辛抱強く仲裁に入る。想像力に富み、楽観的なヴィジョンをもつ。
性格のとらわれが強くなると、表面的にまわりに合わせ、葛藤を避け、実態よりもいい方に理想化して考えてしまう。頑固なまでに現状維持。自分は成長するに値しないと思いがちで、変化へ向けての積極的な行動を起こせない。怒りや不満を直接表現せずに、暗黙の抵抗で示す。不健全なとき、まわりの人から気持ちが離れ、問題に直面することなく、自分を麻痺させて、心地良い空想や嗜癖、フテ寝などに走る。抑鬱や無感覚になる。
平和を好む人がfifa18のCOMエフェクトにキレてコントローラー投げ飛ばしたりするんだろうか…… 謎である。
読書計画(冬)
年末に向けて、読みたい本や持っている本の棚卸。
持っている本
UNIXという考え方
- 作者: Mike Gancarz,芳尾桂
- 出版社/メーカー: オーム社
- 発売日: 2001/02/01
- メディア: 単行本
- 購入: 40人 クリック: 498回
- この商品を含むブログ (145件) を見る
サーバーレスシングルページアプリケーション
サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス
- 作者: Ben Rady,吉田真吾,笹井崇司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/06/23
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
クラウドデザインパターン設計ガイド
Amazon Web Servicesクラウドデザインパターン設計ガイド 改訂版(日経BP Next ICT選書)
- 作者: 玉川憲,片山暁雄,鈴木宏康,野上忍,瀬戸島敏宏,坂西隆之
- 出版社/メーカー: 日経BP社
- 発売日: 2015/07/21
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
シナリオで学ぶパブリッククラウド Amazon Web Services 設計&開発ガイド
シナリオで学ぶパブリッククラウドAmazon Web Services 設計&開発ガイド
- 作者: 大石良,永田明,高橋大成(サーバーワークス),大澤文孝
- 出版社/メーカー: 日経BP社
- 発売日: 2017/06/16
- メディア: 単行本
- この商品を含むブログを見る
TCP/IPネットワーク ステップアップラーニング
[改訂4版]TCP/IPネットワーク ステップアップラーニング
- 作者: 三輪賢一
- 出版社/メーカー: 技術評論社
- 発売日: 2017/11/21
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
みんなのPython
- 作者: 柴田淳
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2016/12/22
- メディア: Kindle版
- この商品を含むブログを見る
持っていない本
アメリカ海軍に学ぶ「最強チーム」のつくり方
アメリカ海軍に学ぶ「最強のチーム」のつくり方: 一人ひとりの能力を100%高めるマネジメント術 (知的生きかた文庫)
- 作者: マイケルアブラショフ,Michael Abrashoff,吉越浩一郎
- 出版社/メーカー: 三笠書房
- 発売日: 2015/05/22
- メディア: 文庫
- この商品を含むブログを見る
- 上司から大切に扱ってもらえないこと
- 積極的な行動を抑えこまれること
- 意見に耳を貸してもらえないこと
- 責任範囲を拡大してもらえないこと
- 給料
Amazon Web Services負荷試験入門
Amazon Web Services負荷試験入門―クラウドの性能の引き出し方がわかる (Software Design plusシリーズ)
- 作者: 仲川樽八,森下健
- 出版社/メーカー: 技術評論社
- 発売日: 2017/09/23
- メディア: 大型本
- この商品を含むブログを見る
SRE サイトリライアビリティエンジニアリング
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
Real World HTTP
Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術
- 作者: 渋川よしき
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/06/14
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
Infrastructure as Code
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
- 作者: Kief Morris,宮下剛輔,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/03/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
ピープルウェア
- 作者: トムデマルコ;ティモシーリスター
- 出版社/メーカー: 日経BP社
- 発売日: 2014/02/05
- メディア: Kindle版
- この商品を含むブログ (34件) を見る
Slackに通知するLambda
Slackにメッセージを飛ばすLambdaつくる。
cloudwatchのアラームをSlackに飛ばしたいと思ったので、
Lambdaを作ってSNSから飛ばす形で作ってみたいと思った。
slack-python-webhook(slackweb)を使って非常に簡単にできる。
lambdaのコード(Python3.6)
# coding: utf-8 import json import slackweb def lambda_handler(event, context): text = event['Records'][0]['Sns']['Message'] print(text) hook_url = "https://hooks.slack.com/services/XXXXXX/XXXXXX/XXXXXXXXXXXXXXXXXXXXXXXX" username = "FromLambda" channel = "#channel" icon_emoji = ":face_with_rolling_eyes:" slack = slackweb.Slack(url=hook_url) slack.notify(text=text, channel=channel, username=username, icon_emoji=icon_emoji)
Lambdaファンクションの作成
# vim lambda_function.py (コードを記載) # vim requirements.txt # # cat requirements.txt slackweb # pip install -r requirements.txt -t ./ # zip -r9 func.zip *
作成したzipファイルを使ってLambdaを作成。
SNSからLambdaに飛ぶように設定する。 SNSが送信するJSONの中身は以下のような感じ。
{ "Records": [ { "EventVersion": "1.0", "EventSubscriptionArn": "arn:aws:sns:EXAMPLE", "EventSource": "aws:sns", "Sns": { "SignatureVersion": "1", "Timestamp": "1970-01-01T00:00:00.000Z", "Signature": "EXAMPLE", "SigningCertUrl": "EXAMPLE", "MessageId": "95df01b4-ee98-5cb9-9903-4c221d41eb5e", "Message": "Hello from SNS!", "MessageAttributes": { "Test": { "Type": "String", "Value": "TestString" }, "TestBinary": { "Type": "Binary", "Value": "TestBinary" } }, "Type": "Notification", "UnsubscribeUrl": "EXAMPLE", "TopicArn": "arn:aws:sns:EXAMPLE", "Subject": "TestInvoke" } } ] }
cloudwatchアラームが発生すると
cloudwatchAlarm→SNS→Lambda→Slackという感じでメッセージが飛んでくる。
【Mackerel】まとめてホストを退役させる
Mackerelでは監視しなくなったホストを、「退役」させることで監視対象外とする。
退役させたいホストがいっぱいある場合、画面からポチポチやるのが面倒なので、
MackerelのCLIを使わせて頂いて、ホストを一気に退役させる。
MackerelのCLIツール mkr
https://mackerel.io/ja/docs/entry/advanced/cli
退役させるコマンド
mkr retire --force host_id
ホストIDを引数に渡してあげればいいので ホスト情報のJSONからjqでホストIDを取り出して渡してあげれば良い。
ホスト一覧を取得。3台のホストが登録されている。
# mkr hosts --service ServiceName --role RoleName | jq '.' [ { "id": "2XXXXXXXXXX", "name": "TST02", "status": "working", "roleFullnames": [ "ServiceName:RoleName" ], "isRetired": false, "createdAt": "Mar 2, 2017 at 2:51am (UTC)", "ipAddresses": { "eth0": "172.20.XX.XX" } }, { "id": "2XXXXXXXXXX", "name": "TST01", "status": "working", "roleFullnames": [ "ServiceName:RoleName" ], "isRetired": false, "createdAt": "Mar 2, 2017 at 2:50am (UTC)", "ipAddresses": { "eth0": "172.20.XX.XX" } }, { "id": "2XXXXXXXXXX", "name": "TST03", "status": "working", "roleFullnames": [ "ServiceName:RoleName" ], "isRetired": false, "createdAt": "Mar 3, 2017 at 7:40am (UTC)", "ipAddresses": { "eth0": "172.20.XX.XX" } } ]
IDだけ取り出す。
# mkr hosts --service ServiceName --role RoleName | jq '.[].id' "2XXXXXXXXXX" "2XXXXXXXXXX" "2XXXXXXXXXX"
いらんもんくっついてる
# jq --help
--raw-output / -r output raw strings, not JSON texts つまり "文字列" → 文字列 みたいに生なヤツを出現させる --compact-output / -c compact instead of pretty-printed output コンパクトに出力してくれる!コンパクトって最高じゃん!とりあえずコンパクトだ!
# mkr hosts --service Practice --role EC2 | jq -r -c '.[].id' 2XXXXXXXXXX 2XXXXXXXXXX 2XXXXXXXXXX
よし。
老兵は死なずただ消し去るのみ。
# for ID in $(mkr hosts --service ServiceName --role RoleName | jq -c -r '.[].id') ;do mkr retire --force ${ID} ;sleep 1 ;done retired 2XXXXXXXXXX(ああ……) retired 2XXXXXXXXXX(ひどい!) retired 2XXXXXXXXXX(そんな……)
本当は引退したくなくても本人の意向を無視して有無を言わせず引退に追い込むので 使う時は気をつける。 なんかタクティクスオウガで部隊から隊員を解雇する時の場面が頭をよぎった。