タグ

2019年12月16日のブックマーク (7件)

  • 【手順】Swap領域の作成方法(AWS, CentOS7.2) - Qiita

    前提 検証OS:CentOS7.2 やること Swap領域の作成(今回は1024MB) →Swap領域はMemoryと同サイズか2倍のサイズにするのが一般的。 /配下にSwap領域(swapvol)を作成する。 参考URL: LINK Swap領域作成手順 1.サーバーにログインし、rootユーザーになる。 # df -h(Swap領域を作成する場所の空き容量を確認) Filesystem Size Used Avail Use% Mounted on /dev/xvda1 30G 3.7G 27G 13% /       ←今回は/領域にSwap領域を作成するので、/の容量を確認 devtmpfs 477M 0 477M 0% /dev tmpfs 496M 0 496M 0% /dev/shm tmpfs 496M 26M 471M 6% /run tmpfs 496M 0 496M

    【手順】Swap領域の作成方法(AWS, CentOS7.2) - Qiita
  • 推奨される Swap 領域の目安 - eTuts+ Server Tutorial

    昔から推奨される Swap 領域の目安として、メモリサイズの 2倍を割り当てておけば良いと教えられ、そう信じて今までサーバ業界で生きてきた私ですが、 最近、調べ物中に必ずしもそうではないという情報を偶然見つけて凄いショックを受けました。 しかも、ストレージ用とシステム用の推奨値が異なるようです。 なぜ 2倍を割り当てるようになったかについて、 改めて調べてみたところ、昔々の話で ページングが多発して実用に耐えない速度の目安が実メモリの2倍だから という説がありました。 題に入る前に簡単に Swap について。 Swap とは、簡単に言うと物理メモリを使い切った場合に、物理メモリの代わりに使われる領域のことで、パーティション、またはファイルを使って作成できますが、推奨されるのは、パーティションです。 あくまでも保険として確保しておく領域なので、物理メモリの代用として使うという考え方は良くあ

    推奨される Swap 領域の目安 - eTuts+ Server Tutorial
    michael-unltd
    michael-unltd 2019/12/16
    “推奨される Swap 領域の目安”
  • Ansible を使って EC2 に ELB アクセスログ分析(Fluentd + ElasticSearch + Kibana4 + Nginx)を立ち上げる - Qiita

    --- - name: Install elasticsearch yum: name="https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-1.6.0.noarch.rpm" state="present" notify: restart elasticsearch - name: Set elasticsearch service to start on boot service: name=elasticsearch enabled=true Fluentd のインストール Ansible Galaxy を見てると、install-redhat-td-agent2.sh の中でやってる処理を Ansible で記述する(Fluentd のインストールはリポジトリを追加して、yum でインストールす

    Ansible を使って EC2 に ELB アクセスログ分析(Fluentd + ElasticSearch + Kibana4 + Nginx)を立ち上げる - Qiita
  • Cloud Dataflow がテンプレートにより気軽に使えるサーバーレスのサービスに進化した話

    よく、 Google Cloud Platform (GCP) のサーバーレスサービスって、 Cloud Functions ですよね? *** ってどうやってやればいいんですか? とか質問をいただくことがあります。この場合の「サーバーレス」の文脈は Function as a Service (FaaS) を指していることが多いと思うんですが、やりたいことをよくよく聞いてみると、「それ、 Cloud Dataflow で、もっと簡単にサーバーレスで出来ますね〜。」、「Google App Engine でももっと簡単に、複雑なことまで出来ますよ〜。」という話になることが多いです。(注:このポストの中では便宜上 Serverless ∋ FaaS とします。) Cloud Dataflow は個人的には超イチオシサービスで、データ処理特化のサーバーレスサービスです。GCP 以外もサポートす

    Cloud Dataflow がテンプレートにより気軽に使えるサーバーレスのサービスに進化した話
    michael-unltd
    michael-unltd 2019/12/16
    “Cloud Dataflow はデータ処理特化のサーバーレスサービスです。GCP 以外もサポートする様々なデータソースとデータのシンク (例: Kafka, S3 等) に対してコネクタがあり、簡単に ETL 処理ができます。”
  • Dataflow と BigQuery を使用した Google Cloud での ETL 処理(Python) | Google Cloud Skills Boost

    GSP290 概要 このラボでは、以下の Google Cloud サービスを使用して複数のデータ パイプラインを構築し、一般公開されているデータセットから BigQuery にデータを取り込みます。 Cloud Storage Dataflow BigQuery 設計上の考慮事項と実装の詳細を反映した独自のデータ パイプラインを作成して、プロトタイプが要件を満たすようにします。指示があった場合は、Python ファイルを開き、コメントを読んでください。 設定 [ラボを開始] ボタンをクリックする前に こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。 このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境

  • Jenkinsfileの書き方 (Jenkins Pipeline) - Qiita

    まずはじめに つい先日、はじめてjenkins pipelineのためのJenkinsfileを作成し、PHPアプリケーションのワンクリックデプロイを実現しました。今回は振り返りの意味も込めて、その際に事前に知っておくと良かった点をまとめていきます。これから、Pipelineを構築したい方は参考にしてみてください。 環境は以下の通りです。 CentOS: 7.3.1611 Jenkins Version: 2.73.2 私の場合は、Pipelineを作成する前にRubyで書かれたCapistranoというデプロイツールでリリース用のスクリプトをすでに構築・運用済みでした。慣れてしまえば十分な環境でしたが、毎回コマンドを叩く手間と増加するチームメンバーへの共有コストを考えるとよりシンプルな手順が必要だと感じてきたため、Jenkinsへの移行を決断しました。 移行プロセスとして、ゼロからCap

    Jenkinsfileの書き方 (Jenkins Pipeline) - Qiita
  • [aws]auto scaling構成でのログ集約を簡単にやりたい - Qiita

    fluentdやらkinesis firehoseやらELKやらathenaやら、いろいろ考えてるとややこしくなってきました。 例えば、新規にaws上にサービスを構築するとして、あまり作りこむこともなく、お金をかけることもなく、って場合にどれがいいのやら。 そういうのを考えながらやってみるエントリでございます。 前提 elb配下でec2がauto scaling構成で稼働している ec2はステートレス ec2上でapacheが稼働している 要件 apacheのログを自動で集約したい ログはDLせずにクラウド上で調査したい 導入は1~2時間くらいで コストは最小限 拡張性もほしい ログが複数行にわたる場合にも対応したい 構成検討 構成としてはec2に何らかのエージェントを入れて、そこからpushする方式とします。 エージェントとして検討するのは、 fluentd kinesis agent

    [aws]auto scaling構成でのログ集約を簡単にやりたい - Qiita
    michael-unltd
    michael-unltd 2019/12/16
    “というわけで、 fluentd + S3 + aws Athenaにしようと思います。”